-XX:-CMSClassUnloadingEnabled (original) (raw)
Tony Printezis tprintezis at twitter.com
Fri Mar 11 16:12:40 UTC 2016
- Previous message (by thread): -XX:-CMSClassUnloadingEnabled
- Next message (by thread): -XX:-CMSClassUnloadingEnabled
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Thanks for the heads up Jungwoo. I think it should be straightforward to decide whether to unload classes for a particular CMS cycle based on the rate at which the meatspace occupancy is growing. Has anyone considered / looked into this?
Tony
On March 10, 2016 at 7:07:00 PM, Jungwoo Ha (jwha at google.com) wrote:
We've been disabled CMSClassUnloading for a long time and had no issues. We recently turned it back on by default with CMSClassUnloadingMaxInterval=5, which amortizes the increased remark cost.
On Thu, Mar 10, 2016 at 1:32 PM, Tony Printezis <tprintezis at twitter.com> wrote: Hi all,
CMSClassUnloadingEnabled is enabled by default in JDK 8. Most of our services do not require class unloading (they load a bunch of classes up-front and that’s it) so we’re thinking of turning it off by default in our JDK as it increases our remark times by a non-trivial amount (40-90ms depending on the service). Any known issues with running with -XX:-CMSClassUnloadingEnabled? (This is a veiled way to ask: is anyone testing with that flag off?)
Thanks,
Tony
Tony Printezis | JVM/GC Engineer / VM Team | Twitter
@TonyPrintezis tprintezis at twitter.com
-- Jungwoo Ha | Java Platform Team | jwha at google.com
Tony Printezis | JVM/GC Engineer / VM Team | Twitter
@TonyPrintezis tprintezis at twitter.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160311/a4331a4d/attachment.htm>
- Previous message (by thread): -XX:-CMSClassUnloadingEnabled
- Next message (by thread): -XX:-CMSClassUnloadingEnabled
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]