-
Bug
-
Resolution: Duplicate
-
P3
-
7u7
-
4P/64C with AMD Opteron™ Processor 6386 SE @ 2.8GhZ
256G of DDR3 RAM
Red Hat Enterprise Linux 6.3JRE version: 7.0_07-b10
Java VM: OpenJDK 64-Bit Server VM (23.6-b03-internal-jvmg mixed mode linux-amd64
-
x86
-
linux
I'm reporting this on behalf of Vasanth Venkatachalam @ AMD.
He says...
We produced a crash using a simple java –version and the flags below, with the java process affinitized to a single core.
$JAVA -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:-UseBiasedLocking -XX:+UseParallelOldGC -Xms12g -Xmx12g -Xmn8g –version
The system details are:
4P/64C with AMD Opteron™ Processor 6386 SE @ 2.8GhZ
256G of DDR3 RAM
Red Hat Enterprise Linux 6.3
Transparent huge pages was disabled and the value in /proc/sys/vm/nr_hugepages had been manually set to 8000. It turned out the crash was due to this being too low a setting for nr_hugepages. When we either bumped up this value, or enabled transparent huge pages (so that this value doesn’t come into play), the crash went away. So this was a large page configuration issue.
Our question is whether the JVM could not crash and rather exit more gracefully with an error message giving some indocation of the problem. How much indication, will depend on whether cases such as the above (where the setting for large pages has been misconfigured) can be detected. At the very least, the JVM shouldn't crash without some message.
He says...
We produced a crash using a simple java –version and the flags below, with the java process affinitized to a single core.
$JAVA -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:-UseBiasedLocking -XX:+UseParallelOldGC -Xms12g -Xmx12g -Xmn8g –version
The system details are:
4P/64C with AMD Opteron™ Processor 6386 SE @ 2.8GhZ
256G of DDR3 RAM
Red Hat Enterprise Linux 6.3
Transparent huge pages was disabled and the value in /proc/sys/vm/nr_hugepages had been manually set to 8000. It turned out the crash was due to this being too low a setting for nr_hugepages. When we either bumped up this value, or enabled transparent huge pages (so that this value doesn’t come into play), the crash went away. So this was a large page configuration issue.
Our question is whether the JVM could not crash and rather exit more gracefully with an error message giving some indocation of the problem. How much indication, will depend on whether cases such as the above (where the setting for large pages has been misconfigured) can be detected. At the very least, the JVM shouldn't crash without some message.
- duplicates
-
JDK-8007074 SIGSEGV at ParMarkBitMap::verify_clear()
- Closed