`zjit_during_incremental_marking` was one process-wide global, written
by `gc_set_incremental_marking` on every transition of any objspace.
Since 24be314b45, two objspaces can run incremental marks at the same
time, so when one finished its mark it wrote zero while another was
still marking.
`gen_write_barrier` skips `rb_gc_writebarrier` when the receiver is young,
not shareable, and the word reads zero, so JIT code in the still-marking
objspace skipped the barrier.
A white object stored into a young black receiver was never marked, the
sweep freed it, and the next major crashed with
```
[BUG] try to mark T_NONE object (parent: T_ARRAY/Array).
```
This bug can be reproduced in a few seconds with
```
RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=0.5 ./ruby --zjit test.rb, where test.rb is:
```
```
Ractor.new {
loop {
GC.start(full_mark: true, immediate_mark: false, global: false)
GC.start(global: false)
}
}
loop {
GC.start(full_mark: true, immediate_mark: false, global: false)
Array.new(2_000) { [nil] }.each { |b|
200.times { Object.new }
sleep 0.0002
b[0] = Object.new
}
}
```
Limiting the oldobject limit factor ensures we keep running majors which
makes this bug easier to trigger, and the array is pre-sized because the
inlined ArrayAset side-exits on an empty array.
This commit moves zjit_incremental_marking into rb_objspace_t and makes
it a bool, so each Ractor can signal to zjit when it's incrementally
marking. Because this is now directly addressable per objspace we've
also removed the incremental marking flag.
Matt Valentine-House
37561263fc