RFR: 8371409: Wrong lock ordering between FullGCALot_lock and ThreadsLockThrottle_lock/MethodCompileQueue_lock
Coleen Phillimore
coleenp at openjdk.org
Wed Dec 3 20:26:07 UTC 2025
On Wed, 3 Dec 2025 12:59:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> 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.
Thanks Robbin and thank you for reporting it.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28633#issuecomment-3608694460
More information about the hotspot-runtime-dev
mailing list