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

Jesper Wilhelmsson jesper.wilhelmsson at oracle.com
Thu Mar 17 17:37:04 UTC 2016

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.

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