RFR: 8329597: C2: Intrinsify Reference.clear [v6]
Aleksey Shipilev
shade at openjdk.org
Thu Oct 3 16:57:39 UTC 2024
On Thu, 3 Oct 2024 12:14:08 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Also dispatch to slow-path on other arches
>
> src/hotspot/share/opto/library_call.cpp line 7002:
>
>> 7000: // Add memory barrier to prevent commoning the accesses in this code,
>> 7001: // since GC can change the value of referent at any time.
>> 7002: insert_mem_bar(Op_MemBarCPUOrder);
>
> I think this CPU memory barrier and comment above are confusing and obviously just taken from the referent loading intrinsics. The commoning it is talking about is to short circuit a second load with the result of a first load of the referent field, since the compiler "knows" the first load would give the "same" answer unless "something happened" (GC clearing it).
> In this case the mutator just cleared it, so what the compiler thinks is that null is stored in that field. And that's completely accurate, and the GC is not going to transition the field from null to some random other object.
> Let's remove this CPU memory barrier and the misleading comments.
Right. I removed it in my local patch queue. Now I have to reconcile this PR with late barrier expansion in G1, I'll push the update once that is done.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1786549120
More information about the core-libs-dev
mailing list