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

[Thomas Schatzl]

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