RFR: ClassUnloadingWithConcurrentMark should be opt-in with Shenandoah

Aleksey Shipilev shade at redhat.com
Wed May 23 13:39:02 UTC 2018


http://cr.openjdk.java.net/~shade/shenandoah/class-unload-optin/webrev.01/

Let's make class unloading with concurrent mark opt-in for Shenandoah. This saves occasional hiccups
on applications that do not need class unloading to begin with. Since ClassUnloading is still
enabled by default, Full GC would unload classes, if it comes to that. "aggressive" heuristics would
unload the classes anyway, so the path that we are disabling for default heuristics is still tested.

The downside is that once the classes start to leak, the class unloading is not there to save the
day, and Init/Final Mark pause time would grow up scanning string table, SystemDictionary and
friends. We can do nothing about it, until concurrent class unloading is implemented upstream.

I have ran our usual benchmarks and saw no regressions in pause times.

Testing: hotspot_gc_shenandoah, specjvm, specjbb

Thanks,
-Aleksey



More information about the shenandoah-dev mailing list