RFR: 8234096: Mutex rank ordering problem JVMTI LoadedClassesClosure and G1 SATB queue
Zhengyu Gu
zgu at redhat.com
Thu Dec 12 14:32:52 UTC 2019
Looks good to me.
Thanks,
-Zhengyu
On 11/19/19 6:56 AM, Roman Kennke wrote:
> 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