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

[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