RFR: 8321815: Shenandoah: gc state should be synchronized to java threads only once per safepoint [v4]

[Aleksey Shipilev]

On Mon, 18 Dec 2023 19:28:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Presently, every change to the gc change is distributed to all java threads. The gc state is only changed on safepoints. For applications with a very large number of java threads this may increase time on the safepoint. It would be better to synchronize the gc state only once per safepoint.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize new _gc_state_changed member.

(Late for the party here!)

The idea looks good, but there are two minor problems with it:

 1. Thread-local gc-state is supposed to be used from the barriers. This is why we can coalesce the thread-local gc-state within a safepoint, as long as we have the proper setup after the safepoint. However, I think it is a happy accident that we don't poll thread-local gc-state from current native barrier code, and thread-local gc-state is only used by java threads. If we ever did access from non-java (gc) threads, this would subtly break GC within e.g. final-mark vmop.
 2. It is fairly weird that now `ShenandoahHeap::set_gc_state_all_threads` does the actual modification, while `ShenandoahHeap::set_gc_state_mask` does not! The names of the methods do not highlight the difference in semantics.

I guess we can hit two birds with one stone if we rename the methods to mention java threads and record/set split, and assert that non-java threads do not touch the `ShenandoahThreadLocalData::_gc_state`. Something like `SH::set_gc_state` (changes the global, sets the propagation flag) and `SH::propagate_gc_state_java_threads` (propagates global to thread-local java threads)?

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

PR Review: https://git.openjdk.org/jdk/pull/17112#pullrequestreview-1788724371