Commit 87cfcff
committed
Only report gc_in_progress if the world is stopped
MMTk core's implementation of `gc_in_progress` returns true when a GC is
requested in MMTk, and completes right at the end of the process. this
means it returns true while the mutators are still running before
they've fully stopped, so there's a window there where it's not safe to
do things that require `gc_in_progress` to be false.
We're seeing this on Ractors where Ractor.take is trying to use
rb_objspace_each_objects, which checks that a GC is not running, but
it's reporting true, because a GC has just been requested.
This commit doesn't rely on MMTk to tell us whether a GC is running, but
uses an AtomicBool in the Ruby binding to track whether or not we've
fully stopped the mutators.
Realistically I think that rb_gc_impl_during_gc_p is badly named now
that we have GC running in seperate threads and are trying to move
towards concurrent GC, but we should tackle this later1 parent 6dd9db5 commit 87cfcff
2 files changed
Lines changed: 9 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
269 | 269 | | |
270 | 270 | | |
271 | 271 | | |
272 | | - | |
| 272 | + | |
273 | 273 | | |
274 | 274 | | |
275 | 275 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
18 | 18 | | |
19 | 19 | | |
20 | 20 | | |
| 21 | + | |
| 22 | + | |
| 23 | + | |
| 24 | + | |
| 25 | + | |
21 | 26 | | |
22 | 27 | | |
23 | 28 | | |
| |||
31 | 36 | | |
32 | 37 | | |
33 | 38 | | |
| 39 | + | |
34 | 40 | | |
35 | 41 | | |
36 | 42 | | |
| |||
48 | 54 | | |
49 | 55 | | |
50 | 56 | | |
| 57 | + | |
| 58 | + | |
51 | 59 | | |
52 | 60 | | |
53 | 61 | | |
| |||
0 commit comments