RFR: 8261495: Shenandoah: reconsider update references memory ordering

[Aleksey Shipilev]

On Wed, 10 Feb 2021 13:37:59 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Shenandoah update heap references code uses default Atomic::cmpxchg to avoid races with mutator updates. Hotspot's default for atomic operations is memory_order_conservative, which emits two-way memory fences around the CASes at least on AArch64 and PPC64.
>> 
>> This seems to be excessive for Shenandoah update references code, and "relaxed" is enough. We do not seem to piggyback on update-references memory effects anywhere (in fact, if not for mutator, we would not even need a CAS).
>> 
>> Sample run with aggressive (back-to-back cycles) on SPECjvm2008:compiler.compiler on AArch64:
>> 
>> # Baseline
>> [135.065s][info][gc,stats] Concurrent Update Refs         =   73.685 s (a =   295924 us) (n =   249) 
>>     (lvls, us =      354,     3418,   349609,   564453,   715405)
>> 
>> # Patched
>> [127.649s][info][gc,stats] Concurrent Update Refs         =   54.389 s (a =   169437 us) (n =   321)
>>     (lvls, us =      324,     2188,   183594,   322266,   394495)
>> 
>> Average time goes down, the number of GC cycles go up, since the cycles are shorter.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 hotspot_gc_shenandoah
>>  - [x] Linux AArch64 hotspot_gc_shenandoah
>>  - [x] Linux AArch64 tier1 with Shenandoah
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 149:
> 
>> 147:   assert(is_aligned(addr, sizeof(narrowOop)), "Address should be aligned: " PTR_FORMAT, p2i(addr));
>> 148:   narrowOop val = CompressedOops::encode(n);
>> 149:   return CompressedOops::decode(Atomic::cmpxchg(addr, c, val, memory_order_relaxed));
> 
> Are you sure it is sufficient? I would think it needs acq/rel pair, otherwise, read side can see incomplete oop ...

Actually, I think you are right: we must ensure the cumulativity of the barriers. Let me think a bit more about it.

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

PR: https://git.openjdk.java.net/jdk/pull/2498