A case where G1/Shenandoah satb barrier is not optimized?

[Roberto Castaneda Lozano]

If the conditions to elide pre- and post-barriers are the same (simply that there is no safepoint poll between the allocation and the write), there is definitely room for improving the optimization. It is however a bit risky to do so at the point in the compilation chain where it is currently performed, since it can be hard to guarantee that subsequent C2 optimizations do not invalidate it (for example, by introducing a new safepoint poll or altering the instruction schedule). This might be a reason why the original optimization is overly restrictive. With late barrier expansion, this optimization could be performed at a much later stage, much like ZGC does [1]. At this stage, we have guarantees that the conditions required for the optimization will not change anymore, which means the optimization can be more aggressive, and safer at the same time.

Cheers,

Roberto

[1] https://github.com/openjdk/jdk/blob/7d53559d2f8f3c27f4d764f081fb031f7660c50b/src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp#L813-L885

________________________________________
From: hotspot-gc-dev <hotspot-gc-dev-retn at openjdk.org> on behalf of Thomas Schatzl <thomas.schatzl at oracle.com>
Sent: Tuesday, March 5, 2024 3:17 PM
To: hotspot-gc-dev at openjdk.org
Subject: Re: A case where G1/Shenandoah satb barrier is not optimized?

Hi,

On 04.03.24 11:32, Yude Lin wrote:
 > Hi Dear GC devs,
 >
 > I found a case where GC barriers cannot be optimized out. I wonder if
 > anyone could enlighten me on this code:
 >
 >  > G1BarrierSetC2::g1_can_remove_pre_barrier (or
 >  > ShenandoahBarrierSetC2::satb_can_remove_pre_barrier)
 >
 > where there is a condition:
 >
 >  > (captured_store == nullptr || captured_store ==
 >  > st_init->zero_memory())
 >
 > on the store that can be optimized out. The comment says:
 >
 >  > The compiler needs to determine that the object in which a field is
 >  > about to be written is newly allocated, and that no prior store to
 >  > the same field has happened since the allocation.
 >
 > But my understanding is satb barriers of any number of stores
 > immediately (i.e., no in-between safepoints) after an allocation can
 > be  optimized out, same field or not.

I think this is correct. SATB only needs the first previous value after
the virtual snapshot has been taken, which is always null for allocating
writes, and so intermediate writes are uninteresting until the next
safepoint. Every field can be considered independently too.

 > The "no prior store" condition confuses me.

Well, to most GC devs most of C2 is somewhat confusing (including me) :)

So there may be many more opportunities to elide barriers for G1 than
what is currently done.

 > What's more, failing to optimize one satb barrier will prevent further
 > barrier optimization that otherwise would be done (maybe due to
 > control flow complexity from the satb barrier).
 >

Hopefully the detection whether one or the other can be elided will
become easier for the compiler to do with the late barrier insertion
changes...


Hth,
   Thomas