On Fri, 27 Sep 2024 18:57:51 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
> > Is ZGC affected by this? I see only G1 and Shenandoah changes. > > Good question. > > ZGC expands the GC barriers late. This is why the IR test configuration that > tests ZGC shows the same result as with other collectors: no additional fluff > in IR. I would not expect we need anything else in late expansion for ZGC for > Reference.clear, but maybe I am tired and cannot see it. Can you confirm this > is fine, @fisk? ZGC needs some changes. Without doing anything, we propagate the AS_NO_KEEPALIVE decorator to the corresponding ZBarrierNoKeepalive bit being set in the barrier data of the StorePNode. However, we don't really do anything special with that information and we will in practice end up keeping the referent alive when clearing it with generational ZGC. The point of introducing the native implementation in the first place, was to make sure our GCs don't keep the referent alive when clearing it, as the user intention is clearly to not keep it alive. I think we need a new ZBarrierSetRuntime::no_keepalive_store_barrier_on_oop_field_without_healing(oop* p) and to make that the selected slow path function when ZBarrierNoKeepalive is set on a StorePNode. Its implementation would call ZBarrier::no_keep_alive_store_barrier_on_heap_oop_field. This should do the trick. Please let me know if you need further assistance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2383479242
