RFR: 8263017: Read barriers are missing in nmethod printing code
Vladimir Ivanov
vlivanov at openjdk.java.net
Thu Mar 11 15:54:18 UTC 2021
OOP accesses from nmethod printing code miss read barriers.
It causes sporadic crashes when the code stumbles upon a stale OOP.
When `nmethod::print_nmethod` is invoked, the corresponding nmethod is already installed in the code cache and there was a safepoint check in between (see `ThreadToNativeFromVM` usage in `CompileBroker::invoke_compiler_on_method`).
The fix adds missing read barriers in `oop_Relocation::oop_value()` and introduces `oop_Relocation::raw_oop_value()` for cases when read barriers aren't needed.
Along the way, there are some cleanups applied (e.g, `nmethod::print_[oops|metadata]` is superseded by `nmethod::print_recorded_[oops|metadata]`).
Testing:
- [x] failing test w/ `-XX:+UseZGC` `-XX:ZCollectionInterval=0.01` `-XX:ZFragmentationLimit=0`
- [x] hs-tier1 - hs-tier4
Thanks!
-------------
Commit messages:
- Fix nmethod print code
Changes: https://git.openjdk.java.net/jdk/pull/2919/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2919&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8263017
Stats: 117 lines in 8 files changed: 28 ins; 71 del; 18 mod
Patch: https://git.openjdk.java.net/jdk/pull/2919.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/2919/head:pull/2919
PR: https://git.openjdk.java.net/jdk/pull/2919
More information about the hotspot-compiler-dev
mailing list