RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint [v3]
Y. Srinivas Ramakrishna
ysr at openjdk.org
Tue Jan 14 20:29:31 UTC 2025
On Tue, 14 Jan 2025 19:56:25 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:
>> Only worker threads and java threads are required to have gclabs. In other use cases (`shHeap::make_labs_parsable`, `shHeap::retire_gclabs`), this closure is _only_ used on java and worker threads, so pushing the test into the closure would be redundant for other uses. I will put in a comment here instead?
>>
>> Additionally, I noticed an inconsistency between `make_labs_parsable` (which skips the safepoint workers) and `retire_gclabs` (which also visited the control thread). An earlier version of this PR had given gclabs to the control and vm threads, but these threads will only perform evacuations in very rare circumstances, so I've removed their gclabs.
>
> Para 1: Yes, that makes sense.
>
> Para 2: I am not sure I follow. Don't we need to cover the _rare_ case where these threads _have_ a gc lab? I agree that the control and vm threads should not need to participate in actual copying work. What is the rare circumstance in which they do need to?
Do control/regulator/vm thread need a local GC state, if they never use an LRB that needs to consult local state? (vide my comment at line 1268 below).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1915540368
More information about the hotspot-gc-dev
mailing list