RFR: 8152113: Remove _last_ditch_collection GC-cause and avoid expanding heap on Metaspace OOM

Jesper Wilhelmsson jesper.wilhelmsson at oracle.com
Fri Mar 18 09:55:21 UTC 2016


OK, thanks.
Ship it!
/Jesper

Den 18/3/16 kl. 09:46, skrev Stefan Johansson:
> Thanks for looking at this Jesper,
>
> I realize I was a bit to brief in my description of the change. Removing
> _last_ditch_collection from is_allocation_failure_gc and
> is_tenured_allocation_failure_gc was made on purpose, as you say
> _last_ditch_collection didn't really belong there. The same goes for the new
> causes, none of them should be used when collecting due to a heap allocation
> failure. The effect of this will be that a Metaspace allocation failure will no
> longer expand the heap for the parallel collector and the same is true for a
> WhiteBox Full GC.
>
> Thanks,
> Stefan
>
> On 2016-03-17 18:37, Jesper Wilhelmsson wrote:
>> Looks good in general.
>>
>> In gcCause.hpp you change the behavior by removing _last_ditch_collection and
>> not adding any of the new causes. Is this intentional? Judging from the name
>> of the two functions where this happens it seems like the right thing to do,
>> but it may have unexpected effects.
>> /Jesper
>>
>>
>> Den 17/3/16 kl. 18:03, skrev Stefan Johansson:
>>> Hi,
>>>
>>> Please review this change for RFE:
>>> https://bugs.openjdk.java.net/browse/JDK-8152113
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~sjohanss/8152113/hotspot.00/
>>>
>>> Summary:
>>> Prior to this patch the GC-cause _last_ditch_collection has been used for 2
>>> types of full-collections that clears soft references:
>>> 1. Last resort when out of metaspace memory
>>> 2. WhiteBox initiated full GC
>>>
>>> These have not much in common and the GC-cause is strangely named when looking
>>> at its meaning. This cause also comes with an unwanted side-effect, it will
>>> expand the heap if possible and this is strange since it is not caused by a
>>> failed heap-allocation. This change removes the _last_ditch_collection cause and
>>> now we instead use two separate causes, _wb_full_gc for the WhiteBox-case and
>>> _metadata_GC_clear_soft_refs for the out of metaspace case. The idea is that
>>> these will work similar to _last_ditch_collection in every way except when it
>>> comes to growing the heap.
>>>
>>> Testing:
>>> Run several tonga test-lists in RBT with G1, CMS and Parallel without seeing any
>>> new issues.
>>>
>>> Thanks,
>>> Stefan
>


More information about the hotspot-gc-dev mailing list