Mark active_units
to avoid SEGV on mjit_recompile and compact_all_jit_code.
For some reason, ISeqs on stack are sometimes GC-ed (why?) and therefore it may run mjit_recompile on a GC-ed ISeq, which I expected d07183ec85d to fix but apparently it may refer to random things if already GC-ed. Marking active_units would workaround the situation. http://ci.rvm.jp/results/trunk-mjit-wait@phosphorus-docker/3292740
Also, while compact_all_jit_code was executed, we saw some SEGVs where CCs seemed to be already GC-ed, meaning their owner ISeq was not marked properly. Even if units are still in active_units, it's not guaranteed that their ISeqs are in use. So in this case we need to mark active_units for a legitimate reason. http://ci.rvm.jp/results/trunk-mjit-wait@phosphorus-docker/3293277 http://ci.rvm.jp/results/trunk-mjit-wait@phosphorus-docker/3293090
Mark active_units
to avoid SEGV on mjit_recompile and compact_all_jit_code.
For some reason, ISeqs on stack are sometimes GC-ed (why?) and therefore
it may run mjit_recompile on a GC-ed ISeq, which I expected d07183ec85d
to fix but apparently it may refer to random things if already GC-ed.
Marking active_units would workaround the situation.
http://ci.rvm.jp/results/trunk-mjit-wait@phosphorus-docker/3292740
Also, while compact_all_jit_code was executed, we saw some SEGVs where
CCs seemed to be already GC-ed, meaning their owner ISeq was not marked
properly. Even if units are still in active_units, it's not guaranteed
that their ISeqs are in use. So in this case we need to mark active_units
for a legitimate reason.
http://ci.rvm.jp/results/trunk-mjit-wait@phosphorus-docker/3293277
http://ci.rvm.jp/results/trunk-mjit-wait@phosphorus-docker/3293090