RFR: 8234096: Mutex rank ordering problem JVMTI LoadedClassesClosure and G1 SATB queue
Roman Kennke
rkennke at redhat.com
Tue Nov 19 11:56:48 UTC 2019
A user reported a mutex rank ordering problem between JVMTI
LoadedClassesClosure and G1's SATB queues. As far as I can tell, this is
caused by JDK-8187577:
ClassLoaderData::loaded_classes_do() acquires the "Metaspace allocation
lock/5" and LoadedClassesClosure tries to enqueue it into G1's SATB
queue, thus attempts to acquire "SATB_Q_CBL_mon/16"
See bug report for more details and discussion.
https://bugs.openjdk.java.net/browse/JDK-8234096
The bug is 8u-specific. I forward-ported the testcase to 11 and 14 (will
post that under different bug-ID asap), and could not reproduce it
there. I also analyzed the code path, and confirmed that the bug is
really not present there.
The fix that I want to propose is simple: instead of enqueueing the oops
during loaded_classes_do() (and thus under lock), we can enqueue it
during extraction of same class-mirrors into the target array. This is
ok because there is no safepoint between the two phases.
Webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8234096/webrev.02/
Testing: The new test fails without the fix, and passes with it.
hotspot_all doesn't show regressions
Can I please get a review for this change?
Thanks, Roman
More information about the jdk8u-dev
mailing list