RFR: 8280917: Simplify G1ConcurrentRefineThread activation [v2]

[Kim Barrett]

On Tue, 1 Feb 2022 07:12:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to to G1ConcurrentRefineThreads to simplify the
>> activation mechanism.
>> 
>> We split the class into two subclasses, one for the "primary" refinement
>> thread and another class for the remaining refinement threads.
>> 
>> The secondary threads are changed to use Monitor-based waits and notifications
>> with a supporting request flag.
>> 
>> The primary thread uses an atomic activation threshold that also serves as "is
>> running" state.  This activation threshold is used by the write barrier
>> support to determine whether the thread's semaphore needs to be signaled.
>> That threshold is now in the primary refinement thread rather than in the
>> dirty card queue set to simplify threshold management and somewhat reduce
>> coupling.
>> 
>> Testing:
>> mach5 tier1-3
>> 
>> Manual tests with refinement thread logging enabled to verify expected
>> activations occur.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 188:

> 186:     // rarely (if ever) dirty cards, so defer activation to a post-safepoint
> 187:     // notification.
> 188:     if (SafepointSynchronize::is_at_safepoint()) {

@walulyai noticed that this test was backward.  Difference in testing is often surprisingly subtle, I suspect because there's enough other wonkiness in the refinement thread control to often mask the effect.  This change as a whole is intended as a step toward fixing that.  I'm sure glad Ivan spotted this now though.

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

PR: https://git.openjdk.java.net/jdk/pull/7282