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

Thomas Schatzl tschatzl at openjdk.org
Fri Mar 14 14:28:57 UTC 2025


On Wed, 12 Mar 2025 13:56:57 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 263:
>> 
>>> 261: 
>>> 262:     SuspendibleThreadSetLeaver sts_leave;
>>> 263:     VMThread::execute(&op);
>> 
>> Can you elaborate what synchronization this VM op is trying to achieve?
>
> Memory visibility for refinement threads for the references written to the heap. Without them, they may not have received the most recent values.
> This is the same as the `StoreLoad` barriers synchronization between mutator and refinement threads imo.

There has been a discussion about whether this is actually needed. Initially we thought that this could be removed because it's only the refinement worker threads that would need memory synchronization, and the memory synchronization is handled by just starting up the refinement threads.

However the rebuild remsets process (marking threads) also access the global card table reference to mark the to-collection-set cards and its value must be synchronized.

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

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


More information about the core-libs-dev mailing list