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.
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.
- relates to
-
JDK-8247748 Investigate default alpha for G1 adaptive IHOP allocation rate
- Open
-
JDK-8245511 G1 adaptive IHOP does not account for reclamation of humongous objects by young GC
- Resolved