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

[Bengt Rutisson]

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
>>
>