On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev <sh...@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
