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