RFR 8085965: VM hangs in C2Compiler
Poonam Bajaj Parhar
poonam.bajaj at oracle.com
Mon Jun 15 18:36:33 UTC 2015
Hello,
Here's the updated webrev:
http://cr.openjdk.java.net/~poonam/8085965/webrev.03/
- Set ExplicitGCInvokesConcurrentAndUnloadsClasses too to false when
ClassUnloading is turned off.
- removed the changes from unpdate_should_unload_classes() in
concurrentMarkSweepGeneration.cpp
- Added the change to mark the classes in genMarkSweep.cpp when
ClassUnloading is off to make sure that classes don't get unloaded with
-XX:-ClassUnloading.
Thanks,
Poonam
On 6/15/2015 7:04 AM, Poonam Bajaj Parhar wrote:
> Hello Kim,
>
> Thanks for the review!
>
> On 6/13/2015 11:53 PM, Kim Barrett wrote:
>> On Jun 11, 2015, at 3:34 PM, Jon Masamitsu <jon.masamitsu at oracle.com>
>> wrote:
>>> 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);
>> That seems wrong to me.
>>
>> It seems to me that the problem here is inconsistencies in the
>> (final) CLA values.
>> I think no change would be needed in
>> concurrentMarkSweepGeneration.cpp if the CLA
>> values were consistent. By consistent here I mean:
> Yes, the problem here is the inconsistent values of ClassUnloading and
> the concurrent-class-unloading options.
>
>> If ClassUnloading is false, then all CLA variations on class
>> unloading must also be false.
>> There are at least:
>>
>> ClassUnloadingWithConcurrentMark
>> CMSClassUnloadingEnabled
>> ExplicitGCInvokesConcurrentAndUnloadsClasses
>>
>> I don’t know if there are more.
>>
>> At least some of those might be false when ClassUnloading is true.
>> And of course, all three of
>> those should be treated as effectively false (and perhaps set false)
>> when a non-concurrent collector
>> is invoked.
>
> I agree that that all the concurrent class unloading options should be
> set false when ClassUnloading is switched off. I will set
> ExplicitGCInvokesConcurrentAndUnloadsClasses too to false as part of
> this fix but would avoid changing the G1 specific option as I won't be
> able to verify the effects of that change for G1.
>
> During the testing another issue was found where class unloading was
> still occurring during Full GC events when running with CMS and
> -XX:-ClassUnloading. And the reason for that was that currently we are
> not marking the classes during the roots processing(in
> mark_sweep_phase1()) even when ClassUnloading is off. The following
> change will fix that problem. The changes are currently under testing
> and I will resubmit the webrev after verification of this change.
>
> gch->gen_process_roots(level,
> false, // Younger gens are not roots.
> true, // activate StrongRootsScope
> SharedHeap::SO_None,
> GenCollectedHeap::StrongRootsOnly, <----
> &follow_root_closure,
> &follow_root_closure,
> &follow_cld_closure);
>
> to
> gch->gen_process_roots(level,
> false, // Younger gens are not roots.
> true, // activate StrongRootsScope
> SharedHeap::SO_None,
> ClassUnloading, <-----
> &follow_root_closure,
> &follow_root_closure,
> &follow_cld_closure);
>
> Thanks,
> Poonam
>
>>
>> I think Gerard’s argument checking work will have some impact here.
>> I’d suggest that there should
>> be constraint functions for these arguments that verify consistency
>> at the end of argument processing.
>>
>>
>
More information about the hotspot-gc-dev
mailing list