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

[William Kemper]

On Wed, 8 Jan 2025 16:25:23 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/shenandoahConcurrentGC.cpp line 1166:
> 
>> 1164:   }
>> 1165: 
>> 1166:   if (VerifyAfterGC) {
> 
> What are the conventions of when to use Verify{Before,After,During}GC on the one hand, vs ShenandoahVerify, G1Verify* etc., on the other?

I don't really think there is a convention. In this particular case, it was "verifying" before concurrent reference processing was complete, which could lead to erroneous verification failures.

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

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