Sorry, the correct commit is 932cda0fe3cbd34e60aa68479935c946f69b756f - "
Simplify GC step calls from on-trace code."
On Mon, Jun 6, 2016 at 7:26 AM, Igor Ehrlich <igor.a.ehrlich@xxxxxxxxx>
wrote:
So I've been looking though the logic of garbage collector integration
with JITed code the other day, and here are a couple of things that bugs me.
1) First and foremost, the GCSatomic/GCSfinalize check in lj_gc_step_jit
might trigger a false positive and an unneeded trace abort. If
lj_gc_step_jit precisely finishes GCSpropagate/GCSsweep and returns, this
check will abort the trace whatsoever. This might be fixed with an
additional flag in GC state. It will be set to 1 inside gc_onestep around
jit_L guards in GCSatomic/GCSfinalize and will be checked and flushed by
lj_gc_step_jit.
2) Regarding the actual guards around GCSatomic, if I read commit message
from d8cb69ed076c3444258f63314662451c9d117cae correctly, the reason for
guarding this step is so freshly created (and thus not "easily" reachable)
objects would not have been swept accidentally. As for me, the solution
seems to be quite obvious here: if "(g->gc.state < GCSatomic)" and we're
creating a string in JIT - make it black. If we're creating a table - make
it gray and push it to gray stack. Same goes for cdata. If this is done,
guarding GCSatomic from inside the JIT code is no longer needed (?) and
stumbling upon this phase will no longer trigger trace abort.
I might possibly be missing something, but I tried the second point
locally and it worked quite well for me.
Thanks in advance for sharing your thoughts on the topic.
Best regards,
Igor A. Ehrlich
