-
Bug
-
Resolution: Unresolved
-
P4
-
26
G1 only uses the next allocation size in a few cases to determine whether the next gc should be a marking. This unnecessarily delays marking/causing instability in the test here:
I.e. 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);
}
}
One cause is that the code to check whether we should do a concurrent start before humongous allocation does take the next allocation into account, while the GC caused by this does not.
I.e. 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);
}
}
One cause is that the code to check whether we should do a concurrent start before humongous allocation does take the next allocation into account, while the GC caused by this does not.
- caused by
-
JDK-8238687 Investigate memory uncommit during young collections in G1
-
- Resolved
-
- links to
-
Review(master)
openjdk/jdk/27789