RFR: 8329597: C2: Intrinsify Reference.clear [v3]

Erik Österlund eosterlund at openjdk.org
Mon Sep 30 15:11:40 UTC 2024


On Fri, 27 Sep 2024 18:57:51 GMT, Aleksey Shipilev <shade at 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


More information about the core-libs-dev mailing list