RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint

[Y. Srinivas Ramakrishna]

On Wed, 8 Jan 2025 06:30:45 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.
>> 
>> The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.
>> 
>> Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2650:
> 
>> 2648: bool ShenandoahHeap::is_gc_state(GCState state) const {
>> 2649:   return _gc_state_changed ? _gc_state.is_set(state) : ShenandoahThreadLocalData::is_gc_state(state);
>> 2650: }
> 
> This needs a documentation comment, please; e.g. why we check `_gc_state_changed` before we check the global state. Is the transition of the local and global states wrt the phase described in a comment somewhere else already?

Or is this a common idiom used elsewhere as well, and already well-documented?

> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 371:
> 
>> 369: public:
>> 370:   char gc_state() const;
>> 371:   bool is_gc_state(GCState state) const;
> 
> Can you write a 1-line documentation comment for this method? It would make its implementation clearer. (See my comment in the method's implementation.)

(e.g. that, unlike comment at line 366, this must return the "right" value even at non-safepoints.)

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

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