-
Type:
Bug
-
Resolution: Won't Fix
-
Priority:
P3
-
None
-
Affects Version/s: 19, 21.0.9
-
Component/s: core-libs
-
other
-
other
ADDITIONAL SYSTEM INFORMATION :
OS: macOS Tahoe 26.1 (ARM64)
CPU: Apple Silicon ARM64
JDK Tested:
- OpenJDK 17.0.17 (Homebrew) - works fast
- OpenJDK 21.0.9 (Homebrew) - significant performance regression
Heap Size Tested: 4GB (-Xms4g -Xmx4g)
A DESCRIPTION OF THE PROBLEM :
A significant performance regression has been identified when running object allocation intensive code on JDK 21 compared to JDK 17. The same test case executes 4-6 times slower on JDK 21, affecting all garbage collectors including low-latency GCs (ZGC, ShenandoahGC) and traditional GCs (G1GC, ParallelGC).
Key Findings:
- ShenandoahGC: 5.23x slower (520ms → 2,718ms)
- ZGC: 5.20x slower (541ms → 2,811ms)
- EpsilonGC: 6.68x slower (526ms → 3,515ms)
- G1GC: 4.69x slower (527ms → 2,471ms)
- ParallelGC: 3.25x slower (497ms → 1,614ms)
The performance degradation appears to be in the core runtime/memory allocation system rather than GC-specific, as even EpsilonGC (no-op GC) shows the worst regression.
This regression affects real-world applications that perform intensive object allocations.
REGRESSION : Last worked in version 17.0.17
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Save the provided test case as Test6916644.java
2. Compile: javac Test6916644.java
3. Run with JDK 17: java -Xms4g -Xmx4g -XX:+UseZGC Test6916644
4. Run with JDK 21: java -Xms4g -Xmx4g -XX:+UseZGC Test6916644
5. Compare execution times (use 'time' command or measure programmatically)
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
JDK 21 should demonstrate similar or better performance than JDK 17 for object allocation intensive workloads, consistent with normal performance improvements in newer JDK versions.
ACTUAL -
JDK 21 executes the same test case 4-6 times slower than JDK 17 across all garbage collector implementations. The performance regression is consistent and reproducible.
---------- BEGIN SOURCE ----------
import java.lang.ref.SoftReference;
import java.lang.ref.WeakReference;
import java.util.ArrayList;
public class Test6916644 {
static int result;
static int i1;
static int i2;
protected static volatile int[][] field_14657;
private static WeakReference[] field_14664;
public static void main(String[] var0) {
Object var1 = null;
field_14664 = new WeakReference[256];
for(int var2 = 0; var2 < 100000; ++var2) {
test((double)(var2 & 1));
}
}
public static void test(double var0) {
int var3;
if (var0 <= (double)0.0F) {
int[][] var10000 = new int[512][16];
new ArrayList();
new ArrayList();
Object var2 = null;
new SoftReference(new Object());
new ThreadGroup("f!l9");
field_14657 = var10000;
var3 = i1;
} else {
var3 = i2;
}
result = var3;
}
}
---------- END SOURCE ----------
OS: macOS Tahoe 26.1 (ARM64)
CPU: Apple Silicon ARM64
JDK Tested:
- OpenJDK 17.0.17 (Homebrew) - works fast
- OpenJDK 21.0.9 (Homebrew) - significant performance regression
Heap Size Tested: 4GB (-Xms4g -Xmx4g)
A DESCRIPTION OF THE PROBLEM :
A significant performance regression has been identified when running object allocation intensive code on JDK 21 compared to JDK 17. The same test case executes 4-6 times slower on JDK 21, affecting all garbage collectors including low-latency GCs (ZGC, ShenandoahGC) and traditional GCs (G1GC, ParallelGC).
Key Findings:
- ShenandoahGC: 5.23x slower (520ms → 2,718ms)
- ZGC: 5.20x slower (541ms → 2,811ms)
- EpsilonGC: 6.68x slower (526ms → 3,515ms)
- G1GC: 4.69x slower (527ms → 2,471ms)
- ParallelGC: 3.25x slower (497ms → 1,614ms)
The performance degradation appears to be in the core runtime/memory allocation system rather than GC-specific, as even EpsilonGC (no-op GC) shows the worst regression.
This regression affects real-world applications that perform intensive object allocations.
REGRESSION : Last worked in version 17.0.17
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Save the provided test case as Test6916644.java
2. Compile: javac Test6916644.java
3. Run with JDK 17: java -Xms4g -Xmx4g -XX:+UseZGC Test6916644
4. Run with JDK 21: java -Xms4g -Xmx4g -XX:+UseZGC Test6916644
5. Compare execution times (use 'time' command or measure programmatically)
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
JDK 21 should demonstrate similar or better performance than JDK 17 for object allocation intensive workloads, consistent with normal performance improvements in newer JDK versions.
ACTUAL -
JDK 21 executes the same test case 4-6 times slower than JDK 17 across all garbage collector implementations. The performance regression is consistent and reproducible.
---------- BEGIN SOURCE ----------
import java.lang.ref.SoftReference;
import java.lang.ref.WeakReference;
import java.util.ArrayList;
public class Test6916644 {
static int result;
static int i1;
static int i2;
protected static volatile int[][] field_14657;
private static WeakReference[] field_14664;
public static void main(String[] var0) {
Object var1 = null;
field_14664 = new WeakReference[256];
for(int var2 = 0; var2 < 100000; ++var2) {
test((double)(var2 & 1));
}
}
public static void test(double var0) {
int var3;
if (var0 <= (double)0.0F) {
int[][] var10000 = new int[512][16];
new ArrayList();
new ArrayList();
Object var2 = null;
new SoftReference(new Object());
new ThreadGroup("f!l9");
field_14657 = var10000;
var3 = i1;
} else {
var3 = i2;
}
result = var3;
}
}
---------- END SOURCE ----------