JDK-8163579 : Improve adaptive IHOP in situations where G1 always aborts the mixed gc phase
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-08-10
  • Updated: 2024-09-24
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-8177704 - Regression in SPECjvm2008.sparse-large because of changes to marking cycle in JDK-8017744
Description
If the application is in a state where the marking cycle is sufficient to reclaim memory in the old generation (no mixed gcs started) for a long time, marking cycles will be started over and over again.

Ie. G1 adaptive IHOP will always stay the same, and may perform way too many marking cycles with no gain.

An application which does so is fft.large from SPECjvm2008.

In such cases, by detecting this case and adapting the IHOP value anyway, the number of marking cycles (and gc overhead) can be cut dramatically.
Comments
specjvm2008.sparse-large is also such a program: it never completes a marking cycle, the default IHOP of 45 and it mostly allocates large short living objects it with the following result: - very frequently does gcs, i.e. every few ms because these humongous allocations cause GCs because of crossing the threshold, using only a fraction of young gen (e.g. after every 2 regions) - this never changes because all (old gen allocation) is humongous objects, so the marking cycles will never complete
20-10-2020