RFR: 8354523: runtime/Monitor/SyncOnValueBasedClassTest.java triggers SIGSEGV

Roman Kennke rkennke at openjdk.org
Tue Apr 15 12:52:51 UTC 2025


When DiagnoseSyncOnValueBasedClasses is != 0, then we can take the slow-path without having cleared the monitor cache in the BasicLock. This would later lead to a crash or other unexpected behaviour. This can happen with C1 or the interpreter, C2 has the DiagnoseSyncOnValueBasedClasses-block after clearing the cache, and the native-entry in sharedRuntime_x86_64.cpp does not have a DiagnoseSyncOnValueBasedClasses-block at all.

The proposed fix so far is a bit ugly because it repeats the clearing code in 3 places. The alternative would be to move the DiagnoseSyncOnValueBasedClasses-block into MA::lightweight_lock(), but this would bring DiagnoseSyncOnValueBasedClasses-handling into the native entry in sharedRuntime_x86_64.cpp, which is currently not the case. Also, we don't have enough regs for that, but we can probably use rscratch1 now that 32-bit is gone (as is already done in C1 and interpreter paths anyway).

I'd first settle on the structure, and then implement the same thing for aarch64.
ping @xmas92

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

Commit messages:
 - 8354523: runtime/Monitor/SyncOnValueBasedClassTest.java triggers SIGSEGV

Changes: https://git.openjdk.org/jdk/pull/24660/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24660&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354523
  Stats: 19 lines in 4 files changed: 14 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24660.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24660/head:pull/24660

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


More information about the hotspot-dev mailing list