RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v11]

[Thomas Schatzl]

On Tue, 4 Mar 2025 15:33:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   iwalulya review
>>     * comments for variables tracking to-collection-set and just dirtied cards after GC/refinement
>>     * predicate for determining whether the refinement has been disabled
>>     * some other typos/comment improvements
>>     * renamed _has_xxx_ref to _has_ref_to_xxx to be more consistent with naming
>
> src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 219:
> 
>> 217:       // The young gen revising mechanism reads the predictor and the values set
>> 218:       // here. Avoid inconsistencies by locking.
>> 219:       MutexLocker x(G1RareEvent_lock, Mutex::_no_safepoint_check_flag);
> 
> Who else can be in this critical-section? I don't get what this lock is protecting us from.

Actually further discussion with @albertnetymk showed that this change introduces an unintended behaviorial change where since the refinement control thread is also responsible for updating the current young gen length.

It means that the mutex isn't required.

However this means that while the refinement is running this is not done any more, because refinement can take seconds, I need to move this work to another thread (probably the `G1ServiceThread´). I will add a separate mutex then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1983587293