RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint [v3]

[Y. Srinivas Ramakrishna]

On Mon, 13 Jan 2025 18:18:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1245:
>> 
>>> 1243:   void do_thread(Thread* thread) override {
>>> 1244:     _propagator.do_thread(thread);
>>> 1245:     if (ShenandoahThreadLocalData::gclab(thread) != nullptr) {
>> 
>> Which thread may have this be null? (I am looking at the ShenandoahRetireGCLabClosure which insists that this should be non-null.)
>> 
>> I assume we have some threads here that have a gc state that must be updated but which don't have a gc lab.
>> 
>> I am wondering if the check for an initialized gclab and in the generational case the plab can be pushed down into the closure rather than being exposed here. At that place, we would want to document (or as needed assert) why some threads targeted by the closure may have null gclab or plab.
>
> 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?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22688#discussion_r1915522467