RFR: 8152113: Remove _last_ditch_collection GC-cause and avoid expanding heap on Metaspace OOM (original) (raw)

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. /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 lastditchcollection 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 lastditchcollection cause and now we instead use two separate causes, wbfullgc for the WhiteBox-case and metadataGCclearsoftrefs for the out of metaspace case. The idea is that these will work similar to lastditchcollection 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