RFR: 8048269: Add flag to turn off class unloading after G1 concurrent mark

[Jon Masamitsu]

On 7/11/2014 1:45 PM, Kirk Pepperdine wrote:
> Hi Jon,
>
> One of the conditions that we run into in the field that has to do with class unloading in CMS is when a regular collection doesn’t recover a lot of memory. I would say there is a recovery threshold (it will be arbitrary) where you’d want to try to unload classes before you hit the conditions for throwing an OOME. The flag could look like ClassUnloadingOccupancyPercent. Set to 0 and you have class unloading on every collection (maybe a reasonable default) or 100% meaning only do it before throwing an OOME.

Kirk,

Do you seem CMS throw an OOME without unloading classes?  I would
have expected the Full GC to unload classes.  I'm pretty sure at one time
it did.

Do  you mean as the CMS generation starts to fill up (and CMS start to 
behave
poorly), consider doing class unloading?

Jon

>
> Just a thought.
>
> Kind regards,
> Kirk
>
> On Jul 11, 2014, at 7:17 PM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
>
>> I think the reason for this flags is that it increases the pause times
>> and some applications care more about pause times than about
>> class bloat.  How about a name like
>>
>> ReduceClassUnloading
>>
>> or
>>
>> UseReducedClassUnloading
>>
>> and add
>>
>> ReducedClassUnloadingInterval
>>
>> where the interval is the number of GC's
>> between class unloading.  Or don't add
>> an interval.  We could add it later or
>> something equivalent if some customer
>> asks for it.
>>
>> The same flag would make sense for STW collectors
>> that might want the same type of option.
>>
>> Jon
>>
>>
>> On 7/11/2014 12:52 AM, Bengt Rutisson wrote:
>>> On 2014-07-11 07:44, Stefan Karlsson wrote:
>>>> On 2014-07-11 01:11, Jon Masamitsu wrote:
>>>>> Could we use a more GC generic name for the flag such as
>>>>> GCClassUnloadingEnabled instead of a G1 specific name and
>>>>> at some point move CMS to use the GC generic name?
>>>> Yes, me and Bengt was talking about that, but IMHO we couldn't come up with a flag with a reasonably short and to-the-point flag name. I don't like the GCClassUnloadingEnabled since it could be mistaken to mean turn of class unloading entirely, which isn't what the flag is supposed to do.
>>>>
>>>> Some of the names we thought about:
>>>>   -XX:+UseConcurrentClassUnloading
>>>>     This sounds we're doing the class unloading concurrently, which isn't the case.
>>>>
>>>>   -XX:+UseConcMarkClassUnloading
>>>>
>>>>   -XX:+UseClassUnloadingAfterConcMark
>>>>
>>>>   -XX:+ClassUnloadingAfterConcMark
>>>>
>>>> Any more suggestions?
>>> Talked some more to Stefan about this.
>>>
>>> The suggestion he made to call it -XX:+ClassUnloadingAfterConcMark is based on that the high level flag to control all class unloading is called -XX:+ClassUnloading. So, this name is kind of a specialization of the overall flag. I kind of like that (even if I think the overall flag should have been called .XX:+UseClassUnloading). However, ConcMark sounds very CMS-like for me. I think my preferred flag name for the moment is:
>>>
>>> -XX:+ClassUnloadingAfterConcurrentMark
>>>
>>> If we introduce a common flag for CMS and G1 I would suggest to deprecate CMSClassUnloadingEnable in JDK9 and have it only be an alias for the new flag. And then remove CMSClassUnloadingEnable in JDK10.
>>>
>>> Thanks,
>>> Bengt
>>>
>>>> thanks,
>>>> StefanK
>>>>
>>>>> Jon
>>>>>
>>>>> On 07/10/2014 08:19 AM, Stefan Karlsson wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Please, review this patch to add code and a flag to turn off class unloading after G1 concurrent mark.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~stefank/8048269/webrev.00/
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8048269
>>>>>>
>>>>>> thanks,
>>>>>> StefanK