RFR (sh/8): Fix lock ordering issue when calling JVMTI GetLoadedClasses during marking

[Zhengyu Gu]

Good to me.

Thanks,

-Zhengyu

On 11/14/19 4:43 PM, Roman Kennke wrote:
> Alexey Genus reported a lock ordering issue involving JVMTI
> GetLoadedClasses() during concurrent marking.
> 
> 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"
> 
> It is not Shenandoah specific, but would also affect G1. See discussion
> and G1 testcase:
> https://bugs.openjdk.java.net/browse/JDK-8234096
> 
> However, it is jdk8u specific. It's been fixed in jdk10 timeframe by
> making loaded-classes-iteration lock-free.
> 
> As far as I can tell, it is not fatal in release build, but it seems
> prudent to fix it anyway, especially because the fix is not difficult.
> Simply not enqueue the oops during loaded_classes_do() but instead
> during extraction of the jclasses, where the Metaspace allocation lock
> is not held.
> 
> While this could go completely via upstream jdk8u, I'd like to push this
> in Shenandoah first, to get it into the hands of Alexey for testing, and
> to bake it a little.
> 
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8234096-shenandoah/webrev.00/
> 
> Testing: The provided testcase fails without the fix, and passes with
> the fix. hotspot_gc_shenandoah looks good.
> 
> Ok to push?
> 
> Roman
>