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

Thomas Schatzl tschatzl at openjdk.org
Tue Mar 4 16:34:56 UTC 2025


On Tue, 4 Mar 2025 16:04:00 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

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

I could create an extra mutex for that if you want to make it clear which two parties access the same data.

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

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


More information about the core-libs-dev mailing list