RFR: 8331714: Make OopMapCache installation lock-free

Aleksey Shipilev shade at openjdk.org
Mon May 6 10:07:24 UTC 2024


Trying to solve [JDK-8331572](https://bugs.openjdk.org/browse/JDK-8331572) runs into all sorts of lock ranking issues with `OopMapCacheAlloc_lock`. I think it would be a bit saner to rewrite the double-checked locking installation to atomic lock-free. OpenJDK code was using this lock since the initial load.

There is a drawback that we might be trying to instantiate multiple `OopMapCache` instances from multiple threads. I think this is not a practical problem, as only a few threads would race here, and the allocation is relatively small (32*8 = 512 bytes). In imaginary worst^W nightmare case, with 100K threads racing we get a temporary native memory spike at +50M.

Additional testing:
 - [ ] Linux x86_64 server fastdebug, `all` tests

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

Commit messages:
 - Touchup comments
 - Fix

Changes: https://git.openjdk.org/jdk/pull/19100/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19100&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331714
  Stats: 12 lines in 3 files changed: 1 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19100.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19100/head:pull/19100

PR: https://git.openjdk.org/jdk/pull/19100


More information about the hotspot-dev mailing list