JDK-8238163 : Improve G1 Adaptive IHOP heuristics
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 15
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2020-01-29
  • Updated: 2022-09-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8245511 - G1 adaptive IHOP does not account for reclamation of humongous objects by young GC
Relates :  
JDK-8247748 - Investigate default alpha for G1 adaptive IHOP allocation rate
Description
Adaptive IHOP calculates the "optimal" point in time to start marking based on allocation rate, marking duration, and a static reserve.

This reserve has been meant to cover allocation spikes; however particularly with small heaps, this reserve is relatively small too (e.g. 10%; i.e. 20M on a 200m heap) which could be filled up quickly, causing unnecessary full gcs.

G1 currently does not use any information to prevent further marking failures, e.g. when a full gc regularly prevents completion of marking to increase the reserve.

Also some runaway issues have been noticed where concurrent marking never starts because as we fill up the heap, the marking threshold rises higher than the heap usage, resulting in full gc.

Some users report more GCs in spiky loads (e.g. https://twitter.com/AndreiPangin/status/1222276375911989250?s=20)

Try to improve one or more of this situations.
Comments
One option to handle spikiness would be to smoothen the input a bit more - currently a *lot* of weight is given to the latest samples.
15-05-2020
Most likely reason for some runaway issues is that currently we base our threshold to start marking among other things on the expected amount of memory needed between mark start and first mixed gc (=X) and allocation rate. Currently that X is continuously updated as we progress in the marking based on young gen size. This is bad because as we go toward end of marking, that young gen size decreases, so the threshold increases. So if our initial calculation of the threshold is bad (too high) because e.g. of highly fluctuating allocation rate, it can happen that we start decreasing X, increasing the threshold, and resulting in marking never started.
15-05-2020
ZGC never reserves more than 5% of the heap according to https://malloc.se/blog/zgc-jdk14 (but at least one "small" ZPage, i.e. 2M)
24-03-2020