-XX:-CMSClassUnloadingEnabled

Srinivas Ramakrishna ysr1729 at gmail.com
Fri Apr 29 18:22:30 UTC 2016


Yes, that was the idea of splitting the two apart, and of allowing the CMS
perm gen to be collected when deemed necessary. The policy of when to
collect was never adequately implemented though and just rode on the flag
to either always or never do it...

It would be good to get this cleaned up and implemented, given the cost on
the remark phases as we seem to be (re)discovering each time we enable it
on by default ... old CMS hands will remember the tortured history of this
:-)

-- ramki


On Fri, Mar 11, 2016 at 10:32 AM, Mikael Gerdin <mikael.gerdin at oracle.com>
wrote:

>
>
> On 2016-03-11 18:29, Jon Masamitsu wrote:
>
>>
>>
>> On 3/11/2016 8:12 AM, Tony Printezis wrote:
>>
>>> 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?
>>>
>>
>> No one has looked at this to my knowledge.
>>
>
> Another, perhaps simpler, alternative would be to enable class unloading
> for a single CMS cycle at
>   if (MetaspaceGC::should_concurrent_collect()) {
>     log_trace(gc)("CMSCollector: collect for metadata allocation ");
>     return true;
>   }
>
> This would cause metaspace allocation triggered CMS cycles to unload
> classes at least.
>
> /Mikael
>
>
>> Jon
>>
>>
>>> Tony
>>>
>>> On March 10, 2016 at 7:07:00 PM, Jungwoo Ha (jwha at google.com
>>> <mailto: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
>>>> <<mailto:tprintezis at twitter.com>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 <mailto:tprintezis at twitter.com>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jungwoo Ha | Java Platform Team | jwha at google.com
>>>> <mailto:jwha at google.com>
>>>>
>>>> -----
>>>
>>> Tony Printezis | JVM/GC Engineer / VM Team | Twitter
>>>
>>> @TonyPrintezis
>>> tprintezis at twitter.com <mailto:tprintezis at twitter.com>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160429/50ebea0e/attachment.htm>


More information about the hotspot-gc-dev mailing list