-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
Doing heap sizing based on garbage collections has a big disadvantage: if there are no garbage collections (due to no application activity) there is a risk that a large amount of heap is kept committed unnecessarily for a long time.
There needs to be some other form of regular re-evaluation of heap size to combat that.
This also somewhat ties in with JDK-8213198 that is about regularly cleaning out other resources (although in that case it can happen that there is lots of gc activity, but just no whole heap analysis for a long time)
There are also periodic GCs (
Another option is to regularly trigger a young gc (without concurrent start/whole heap analysis), but that may be a too large disruption.
ZGC tracks last-used time of a region and regularly uncommits those that have not been in use for a certain amount of time (ZUncommitDelay; as the only strategy to free heap regions currently).
- is blocked by
-
JDK-8238687 Investigate memory uncommit during young collections in G1
-
- Resolved
-
- relates to
-
JDK-8213198 Not triggering concurrent cycle in G1 leaves string table cleanup deferred
-
- Open
-
-
JDK-8359211 Automatic Heap Sizing for G1
-
- Draft
-
- links to
-
Review(master) openjdk/jdk/26207
-
Review(master) openjdk/jdk/26240