RFR: ClassUnloadingWithConcurrentMark should be opt-in with Shenandoah
Roman Kennke
rkennke at redhat.com
Wed May 23 15:46:08 UTC 2018
I assume that traversal & co do the right thing too?
Am 23. Mai 2018 15:39:02 MESZ schrieb Aleksey Shipilev <shade at redhat.com>:
>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
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
More information about the shenandoah-dev
mailing list