RFR: 8371409: Wrong lock ordering between FullGCALot_lock and ThreadsLockT… d0522e9 …hrottle_lock/MethodCompileQueue_lock

Coleen Phillimore coleenp at openjdk.org
Wed Dec 3 13:08:38 UTC 2025


This changes the rank of FullGCALot_lock to nosafepoint since it's taken when we want to do FullGCALot when we take safepoint lock so should always be a rank below that.  This lock is very limited in what it does - it only protects some memory that we allocate at the bottom/beginning of the heap so that full gc with older collectors has to move stuff.
Tested with tier1-4.  I wrote a test case where I verified this change but the test case times out, so noreg-hard.

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

Commit messages:
 - Remove the test.  FullGCALot times out.
 - 8371409: Wrong lock ordering between FullGCALot_lock and ThreadsLockThrottle_lock/MethodCompileQueue_lock

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

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


More information about the hotspot-runtime-dev mailing list