RFR: 8329597: C2: Intrinsify Reference.clear

[Aleksey Shipilev]

On Thu, 11 Jul 2024 15:28:37 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:
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [ ] Linux AArch64 server fastdebug, `all`

Split out the `refersTo` test to https://github.com/openjdk/jdk/pull/20215.

Yeah, so this version seems to work well on tests.

I am being extra paranoid about only accepting `null` stores, since `AS_NO_KEEPALIVE` means all other barriers like inter-generational post-barriers in G1 should still work. G1 barrier set delegates the stores to `CardTable/ModRefBarrierSet`, which: a) does not know which barriers can be bypassed by `AS_NO_KEEPALIVE`; b) calls back `G1BarrierSet` for prebarrier generation, but already loses the decorators. So the simplest way to deal with this is to handle this special case specially.

I think this is insanely sane, given how sharp-edged `AS_NO_KEEPALIVE` is.

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

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2233066721
PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2234005550