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

[William Kemper]

On Tue, 14 Jan 2025 20:13:34 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> 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).

The control thread runs the final steps of concurrent reference processing in which the list of references that have been cleared is constructed and published to a reference in the heap (see Universe::_reference_pending_list). The VM thread may also need to evacuate objects when a heap dump is taken during the concurrent evacuation phase. When the heap dump is taken by parallel threads, it will use the worker threads and these _will_ have `gclabs`. However, in some cases, the VM thread itself will walk the heap and perform evacuations. In these cases when the VM thread or control thread evacuate objects, they will fallback to `shared` allocations. These two threads still execute the load-reference-barrier and need a local GC state (possibly the VM thread would not need it, but I'm erring on the side of caution).

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

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