RFR: 8375643: G1: Convert G1RegionMarkStatsCache to use Atomic<T>

Thomas Schatzl tschatzl at openjdk.org
Tue Jan 20 10:40:19 UTC 2026


On Tue, 20 Jan 2026 10:21:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1RegionMarkStatsCache.hpp line 119:
>> 
>>> 117:   void add_live_words(uint region_idx, size_t live_words) {
>>> 118:     G1RegionMarkStatsCacheEntry* const cur = find_for_add(region_idx);
>>> 119:     cur->_stats._live_words.store_relaxed(cur->_stats.live_words() + live_words);
>> 
>> Is this just `add_then_fetch` with `memory_order_relaxed` then? Or are we trying to dodge some performance penalty avoiding the atomic RMW instructions? I suspect x86 still implicitly does CAS memory effects when doing `cmpxchg` on memory location; `memory_order_relaxed` would not help there.
>
> Actually, what _are_ the atomicity requirements here? Is this code supposed to be called on same region stats by multiple threads? Or is this single threaded?

In this method there are no atomic requirements. It is only called by a single thread. The only atomic requirements is when merging it down to a global table using `evict()`. However since that method requires an `Atomic`, we need to use `load/store_relaxed()` here anyway.

It took me some time too to understand that the code is correct too. Should I add some comments?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29303#discussion_r2707763319


More information about the hotspot-gc-dev mailing list