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.

The concurrent refine control thread in `G1ConcurrentRefineThread::do_refinement`, when calling `G1Policy::record_dirtying_stats`.

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

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