JDK-8368959 : G1: IHOP calculation selects very low threshold and stays there
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 23
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2025-09-30
  • Updated: 2025-10-03
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.
JDK 26
26Unresolved
Related Reports
Relates :  
Relates :  
Description
When running this program with -Xms100M -Xmx100M, beginning with JDK 23 (b08?) G1 starts behaving very badly as automatic IHOP kicks in: it reduces the heap size to zero, effectively using 5M of heap from then on.

This results in ~900 garbage collections, which are always concurrent start ones.

public class MixedGcHumongous {
    public static void main(String[] args) throws Exception {
        System.gc(); // start from stable state
        for (int i = 0; i < 1000; i++) {
            Integer[] humongous = new Integer[200_000]; Thread.sleep(10); // ~0.8MB (humongous)
            allocateTempNormal(20_000); Thread.sleep(10); // 40 bytes per entry = ~2MB
        }
    }
    static void allocateTempNormal(int count) throws Exception {
        java.util.LinkedList<Integer> temp = new java.util.LinkedList<>();
        for (int j = 0; j < count; j++) temp.add(j);
    }
}

The difference seems to be that in earlier JDK versions, G1 never reaches the point where adaptive IHOP kicks in, so heap is limited to the default IHOP (45%).

This is also kind of "fixed" (more worked around) with JDK-8048180 eager reclaim of humongous objects with references, but obviously that is incidental.
Comments
I.e. the memory allocation tracking code does not take reclamation of empty regions during Remark into account at all. Seems to be a problem caused/introduced by JDK-8245511.
03-10-2025

At least in this test this is due to highly overestimating the humongous object allocation rate. It is around 40-50MB/s, which pushes down the IHOP. The current policy does not take into account that they are actually reclaimed at the next remark pause (which happens quite early). With JDK-8048180 the allocation rate is much reduced because we eager reclaim all these regions. Note that temporarily these allocation need to be stored somewhere.
02-10-2025

I think this is a day-one bug - it is only prevented by earlier JDKs not activating adaptive IHOP.
30-09-2025