A guarantee failure with CMSClassUnloadingMaxInterval
yamauchi at google.com
Fri May 17 18:27:43 UTC 2013
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
More information about the hotspot-gc-dev