-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Simplify sweeping of big values #54936
base: master
Are you sure you want to change the base?
Conversation
Marking as draft until the x64 failure is investigated. |
8020759
to
a271d93
Compare
Btw, since you are changing this code, is the linked list an efficient enough data structure for this? I haven't measured the overhead of sweeping through this so I'm not sure but it's potentially a place where we spent some time pointer chasing. |
1b7041f
to
3ad2b27
Compare
Probably? Note that the sweeping code will need to access the GC bits in |
f1c762c
to
64b1fe4
Compare
3a59ea4
to
be08e43
Compare
Re-ran the benchmarks and looks close to performance neutral on the serial & multithreaded GCBenchmarks. Serial ones were run with 1 thread, multithreaded ones with 8 mutators and 8 GC threads.
|
be08e43
to
1f81f32
Compare
Simplifies the layout of the doubly linked list of big objects to make it a bit more canonical: let's just store a pointer to the previous element, instead of storing a "pointer to the next element of the previous element". This should make the implementation a bit easier to understand without incurring any memory overhead.
Also introduces thread-local lists of objects that need to be fixed up due to
mark_reset_age
, and does this fix-up in the sweeping itself: doing it in the mark phase as we're doing it now is quite confusing and may introduce contention since we need to grabgc_cache_lock
when doing so.I ran the serial and multithreaded benchmarks from GCBenchmarks and this seems fairly close to performance neutral on my machine, but more benchmarking is needed.