-
Bug
-
Resolution: Not an Issue
-
P3
-
None
-
8
-
x86_64
-
linux
A DESCRIPTION OF THE PROBLEM :
I have encountered a significant performance issue when running a Java test case on Ubuntu 20.04.4 LTS using Hotspot JDK 1.8.0_431. Approximately 97% of the user time is spent executing garbage collection (GC) algorithms with the default ParallelGC, resulting in a real execution time of around 2 minutes and 51 seconds. However, when using OpenJ9 JDK 8u432-b06 or Hotspot JDK 1.8.0_431 with the G1GC garbage collector, the execution time drops to just a few seconds. Additionally, running the same test on Windows yields short execution times, further indicating that the issue is specific to the Linux environment with ParallelGC.I suspect that the default ParallelGC in this version of the Hotspot JVM has performance issues on Linux systems. I can provide GC logs for further analysis.
REGRESSION : Last worked in version 8
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Using Hotspot JDK with default ParallelGC: time /root/hotspot/jdk1.8.0_431/bin/java -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/root/example/gc.log Test
Using OpenJ9 JDK: time /root/openj9/jdk8u432-b06/bin/java Test
Using Hotspot JDK with G1GC: time /root/hotspot/jdk1.8.0_431/bin/java -XX:+UseG1GC Test
Using Hotspot JDK with windows and default ParallelGC : Measure-Command { D:\development_tools\JDK8_HOT\bin\java.exe -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:D:\code\java\test\gc.log test }
ACTUAL -
Hotspot JDK 1.8.0_431 with default ParallelGC:
real 3m29.283s
user 283m14.400s
sys 0m52.860s
OpenJ9 JDK 8u432-b06:
real 0m15.510s
user 1m59.276s
sys 0m17.718s
Hotspot JDK 1.8.0_431 with G1GC:
real 0m7.403s
user 2m23.107s
sys 0m16.017s
On Windows using Hotspot JDK with default ParallelGC:
Days : 0
Hours : 0
Minutes : 0
Seconds : 22
Milliseconds : 396
Ticks : 223960214
TotalDays : 0.000259213210648148
TotalHours : 0.00622111705555555
TotalMinutes : 0.373267023333333
TotalSeconds : 22.3960214
TotalMilliseconds : 22396.0214
---------- BEGIN SOURCE ----------
import java.util.Arrays;
public class test {
static final int LOOP = 30000000;
static class V16qi {
byte[] values = new byte[16];
V16qi() {}
V16qi(byte[] values) {
this.values = values;
}
}
public static void main(String[] args) {
V16qi[] p0 = new V16qi[LOOP];
V16qi[] p1 = new V16qi[LOOP];
for (int i = 0; i < LOOP; i++) {
byte[] array0 = new byte[16];
byte[] array1 = new byte[16];
for (int j = 0; j < 16; j++) {
array0[j] = (byte) (1 + i + j);
array1[j] = (byte) (1 + i * i + j * j);
}
p0[i] = new V16qi(array0);
p1[i] = new V16qi(array1);
}
}
}
---------- END SOURCE ----------
I have encountered a significant performance issue when running a Java test case on Ubuntu 20.04.4 LTS using Hotspot JDK 1.8.0_431. Approximately 97% of the user time is spent executing garbage collection (GC) algorithms with the default ParallelGC, resulting in a real execution time of around 2 minutes and 51 seconds. However, when using OpenJ9 JDK 8u432-b06 or Hotspot JDK 1.8.0_431 with the G1GC garbage collector, the execution time drops to just a few seconds. Additionally, running the same test on Windows yields short execution times, further indicating that the issue is specific to the Linux environment with ParallelGC.I suspect that the default ParallelGC in this version of the Hotspot JVM has performance issues on Linux systems. I can provide GC logs for further analysis.
REGRESSION : Last worked in version 8
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Using Hotspot JDK with default ParallelGC: time /root/hotspot/jdk1.8.0_431/bin/java -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/root/example/gc.log Test
Using OpenJ9 JDK: time /root/openj9/jdk8u432-b06/bin/java Test
Using Hotspot JDK with G1GC: time /root/hotspot/jdk1.8.0_431/bin/java -XX:+UseG1GC Test
Using Hotspot JDK with windows and default ParallelGC : Measure-Command { D:\development_tools\JDK8_HOT\bin\java.exe -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:D:\code\java\test\gc.log test }
ACTUAL -
Hotspot JDK 1.8.0_431 with default ParallelGC:
real 3m29.283s
user 283m14.400s
sys 0m52.860s
OpenJ9 JDK 8u432-b06:
real 0m15.510s
user 1m59.276s
sys 0m17.718s
Hotspot JDK 1.8.0_431 with G1GC:
real 0m7.403s
user 2m23.107s
sys 0m16.017s
On Windows using Hotspot JDK with default ParallelGC:
Days : 0
Hours : 0
Minutes : 0
Seconds : 22
Milliseconds : 396
Ticks : 223960214
TotalDays : 0.000259213210648148
TotalHours : 0.00622111705555555
TotalMinutes : 0.373267023333333
TotalSeconds : 22.3960214
TotalMilliseconds : 22396.0214
---------- BEGIN SOURCE ----------
import java.util.Arrays;
public class test {
static final int LOOP = 30000000;
static class V16qi {
byte[] values = new byte[16];
V16qi() {}
V16qi(byte[] values) {
this.values = values;
}
}
public static void main(String[] args) {
V16qi[] p0 = new V16qi[LOOP];
V16qi[] p1 = new V16qi[LOOP];
for (int i = 0; i < LOOP; i++) {
byte[] array0 = new byte[16];
byte[] array1 = new byte[16];
for (int j = 0; j < 16; j++) {
array0[j] = (byte) (1 + i + j);
array1[j] = (byte) (1 + i * i + j * j);
}
p0[i] = new V16qi(array0);
p1[i] = new V16qi(array1);
}
}
}
---------- END SOURCE ----------
- relates to
-
JDK-8310031 Parallel: Implement better work distribution for large object arrays in old gen
-
- Resolved
-
-
JDK-8321013 Parallel: Refactor ObjectStartArray
-
- Resolved
-