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

[Erik Österlund]

On Mon, 30 Sep 2024 16:59:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [ ] Linux x86_64 server fastdebug, `all`
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also dispatch to slow-path on other arches

Changes requested by eosterlund (Reviewer).

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.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20139#pullrequestreview-2345438249
PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1786116003