RFR 8085965: VM hangs in C2Compiler

[Jon Masamitsu]

Poonam,

Thanks for the changes.

What do you think about deleting this part of the
change (line 2759) from the flag processing?
It feels like we're fixing something in two places where
as we only really need the change in
Arguments::set_cms_and_parnew_gc_flags().

http://cr.openjdk.java.net/~poonam/8085965/webrev.01/src/share/vm/runtime/arguments.cpp.frames.html

2759       FLAG_SET_CMDLINE(bool, CMSClassUnloadingEnabled, false);


Jon

On 06/11/2015 11:12 AM, Poonam Bajaj Parhar wrote:
> Hello Jon,
>
> Here's the updated webrev:
> http://cr.openjdk.java.net/~poonam/8085965/webrev.01/
>
> Thanks,
> Poonam
>
> On 6/11/2015 6:45 AM, Poonam Bajaj Parhar wrote:
>> Hello Jon,
>>
>> Thanks for taking a look at the code changes:
>>
>> On 6/10/2015 6:42 PM, Jon Masamitsu wrote:
>>> Poonam,
>>>
>>> http://cr.openjdk.java.net/~poonam/8085965/webrev/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp.frames.html
>>>
>>> I think it reads more easily if it is coded like this
>>>
>>> if (!ClassUnloading) {
>>>   _should_unload_classes = false;
>>> } else if ((_full_gc_requested && 
>>> ExplicitGCInvokesConcurrentAndUnloadsClasses) {
>>>    _should_unload_classes = true
>>>  } else if (CMSClassUnloadingEnabled) {
>>>   // Condition 2.a above 2678
>>>  // Disjuncts 2.b.(i,ii,iii) above
>>>    _should_unload_classes = (concurrent_cycles_since_last_unload() >=
>>> CMSClassUnloadingMaxInterval)
>>>                                                  || 
>>> _cmsGen->is_too_full();
>>>  }
>>>
>>> I might not have cut-and-pasted it right but I think you can see 
>>> what I mean.
>>>
>> I understand, will make this change.
>>
>>> Also fix the block comment above to say that ClassUnloading overides 
>>> the other
>>> conditions.
>>>
>> yes.
>>
>>> http://cr.openjdk.java.net/~poonam/8085965/webrev/src/share/vm/runtime/arguments.cpp.frames.html
>>>
>>>
>>> This catches the case where -Xnoclassgc is used but does not catch 
>>> if -XX:-ClassUnloading is used.  Yes?
>>> 2752     } else if (match_option(option, "-Xnoclassgc")) {
>>> 2753       FLAG_SET_CMDLINE(bool, ClassUnloading, false);
>>> 2754       FLAG_SET_CMDLINE(bool, CMSClassUnloadingEnabled, false);
>>>
>>> Instead if you add in "share/vm/runtime/arguments.cpp" to the method
>>>
>>> 1262 void Arguments::set_cms_and_parnew_gc_flags() ;
>>>
>>> if (!ClassUnloading) {
>>> FLAG_SET_CMDLINE(bool, CMSClassUnloadingEnabled, false);
>>> }
>>>
>> Oops! I missed it; will add it.
>>
>> Thanks,
>> Poonam
>>
>>
>>> That should catch both -Xnoclassgc and -XX:-ClassUnloading
>>>
>>> Jon
>>>
>>> On 6/10/2015 2:20 PM, Poonam Bajaj Parhar wrote:
>>>> Please review the code changes to fix:
>>>> JDK-8085965: <https://bugs.openjdk.java.net/browse/JDK-8085965> VM 
>>>> hangs in C2Compiler
>>>>
>>>> Problem and fix:
>>>> In JDK8, CMSClassUnloadingEnabled option which is used to control 
>>>> the class-unloading in CMS, was enabled by default. But if the user 
>>>> specifies -Xnoclassgc or -XX:-ClassUnloading on the command line 
>>>> then classes get unloaded but updating of subklasses/siblings links 
>>>> gets skipped by the ClassUnloading check in the following function:
>>>>
>>>> /void Klass::clean_weak_klass_links(BoolObjectClosure* is_alive, 
>>>> bool /
>>>> /clean_alive_klasses) {/
>>>> /   if (!ClassUnloading) {/
>>>> /     return;/
>>>> /   }
>>>>
>>>> /which corrupts the class hierarchy links causing hangs and crashes.
>>>>
>>>> This fix honors -XX:-ClassUnloading and -Xnoclassgc options and 
>>>> disables class unloading with CMS.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~poonam/8085965/webrev/
>>>>
>>>> Thanks,
>>>> Poonam
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150611/16bd68eb/attachment.htm>