A guarantee failure with CMSClassUnloadingMaxInterval

Hiroshi Yamauchi yamauchi at google.com
Fri May 17 18:27:43 UTC 2013


Hi Stefan,

Thanks for more information.

On Thu, May 16, 2013 at 2:24 PM, Stefan Karlsson
<stefan.karlsson at oracle.com> wrote:
> On 5/16/13 11:16 PM, Stefan Karlsson wrote:
>>
>> On 5/16/13 10:31 PM, Hiroshi Yamauchi wrote:
>>>
>>> Hi Ramki,
>>>
>>>> I can't recall the history behind the flag for class unloading every N
>>>> Concurrent collections, but your analysis appears spot on to me. I can
>>>> review the code tomorrow morning and confirm since its been a while since I
>>>> looked at this code...
>>>
>>> I suppose that it's not a flag that's commonly used. It'd be great if
>>> you can take a look.
>>
>>
>> FYI, I ran some parallel class loading tests with with
>> -XX:CMSClassUnloadingMaxInterval=5 and get similar kind of failures.
>>
>> We probably treat the Klasses as weak roots when we shouldn't, or
>> something similar.
>
>
> And now I re-read your first post and see that you have already come to that
> conclusion. FWIW, I get verification failures if I run this with JDK8 +
> -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:+VerifyAfterGC.

By "treat(ing) the Klasses as weak roots", do you mean the choice
between SO_AllClasses and SO_SystemClasses? If so, yes, I think we're
on the page.

If JDK8 gets a verification failure, then regardless of whether this
guarantee fails or not, it sounds like there's something wrong
somewhere.

>
> thanks,
> StefanK
>>
>>
>> StefanK
>>>
>>>
>>> Thanks.
>>
>>
>



More information about the hotspot-gc-dev mailing list