-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add parallel marking to GC #41760
Add parallel marking to GC #41760
Conversation
Codecov Report
@@ Coverage Diff @@
## master #41760 +/- ##
==========================================
+ Coverage 80.02% 80.06% +0.03%
==========================================
Files 350 350
Lines 73943 74011 +68
==========================================
+ Hits 59170 59254 +84
+ Misses 14773 14757 -16
Continue to review full report at Codecov.
|
It just means that you are reading garbage somehow. |
Ok to close this? |
@ViralBShah we have someone actively working on getting this PR up to date, who may end up pushing to this PR or another one (in which case we'll supersede this). I'd like to keep this open until that happens, just so people have something to watch for progress updates. |
Superseded by #44643 |
This is a first pass at multithreading parts of GC marking. The intended approach is simple: Store a "recruitment location" (function address) into a global, and have non-leader threads (those not running
_jl_gc_collect
directly) check for this global to be set to non-NULL
. Threads that encounter a valid recruitment location will set their GC state to the newJL_GC_STATE_PARALLEL
(name subject to change), and will call into the recruitment location. The only available recruitment function,gc_mark_loop_recruited
, will put the thread to work ingc_mark_loop
, assuming that the GC leader thread setup some work for this thread to do.I'm posting this PR early because I need some help figuring out what I'm doing wrong. So far, the recruitment mechanism seems to work well, but I haven't figured out what things I need to setup for each thread before letting them enter the mark loop.
I've also got some code commented out, which would (presumably, if it worked) allow threads to steal work from each other. That's probably not required for this PR, but I started on it in case it might be useful.
N.B. I am bad at atomics, thread safety, and GC semantics, so please point out what terrible things I have done here!
@vchuravy @vtjnash