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

Yude Lin yude.lyd at alibaba-inc.com
Mon Mar 4 10:32:12 UTC 2024


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.
The "no prior store" condition confuses me.
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).
An example would be:
public static class TwoFieldObject {
 public Object ref;
 public Object ref2;
 public TwoFieldObject(Object a) {
 ref = a;
 }
}
public static Object testWrite(Object a, Object b, Object c) {
 TwoFieldObject tfo = new TwoFieldObject(a);
 tfo.ref = b; // satb barrier of this store cannot be optimized out, and because of its existence, post barrier will also not be optimized out
 tfo.ref2 = c; // because of the previous store's barriers, pre/post barriers of this store will not be optimized out
 return tfo;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20240304/49fa8e98/attachment.htm>


More information about the hotspot-gc-dev mailing list