JDK-8167501 : ARMv7 Linux C2 compiler crashes running jtreg harness on MP systems
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: arm
  • Submitted: 2016-10-11
  • Updated: 2017-08-09
  • Resolved: 2016-11-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 9
9 b146Fixed
Related Reports
Relates :  
JDK-8153107 - enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs
Description
The jtreg hardness crashes when run on a quad-core ARMv7 system
using the C2 server VM.

Most of the crashes are guarantees failed in the locking/unlock code.
The jtreg hardness hangs sometimes rather than crashing.

Here's one failure example:

Internal Error at synchronizer.cpp:1445, pid=4700, tid=4859
assert(dmw->is_neutral()) failed: invariant

#8  0xb68b2d2a in ObjectSynchronizer::inflate(Thread*, oopDesc*, ObjectSynchroni
zer::InflateCause) () from /export/users/bobv/jdk/lib/arm/server/libjvm.so
#9  0xb68b00b8 in ObjectSynchronizer::fast_exit(oopDesc*, BasicLock*, Thread*)
    () from /export/users/bobv/jdk/lib/arm/server/libjvm.so
#10 0xb68b036e in ObjectSynchronizer::slow_exit(oopDesc*, BasicLock*, Thread*)
    () from /export/users/bobv/jdk/lib/arm/server/libjvm.so
#11 0xb6846ed8 in SharedRuntime::complete_monitor_unlocking_C(oopDesc*, BasicLoc
k*, JavaThread*) () from /export/users/bobv/jdk/lib/arm/server/libjvm.so

Here is the command I used to reproduce the failure:

/export/users/bobv/jdk/bin/java -XX:+PrintCompilation  -server -XX:+ShowMessageBoxOnError -jar jtreg/lib/jtreg.jar -nr -othervm -timeout:3 -conc:4 -v1 -a -ignore:quiet -jdk:/export/users/bobv/jdk /export/users/bobv/jdk9-arm3264/hotspot/test

Notes:

1. The failures seem to be independent of GC's.  It fails with G1, Serial and ParallelGC.

2. It fails with biased locking disable or enabled.

3. I have not been able to reduce the crash using the JDK 8 ARMv7 C2 compiler.

4. The failure does not reproduce when using the C1 compiler.

5. The failure occurs with fast debug and slow debug builds.

6. If I run the harness using -Xcomp, the crash occurs fairly quickly once the harness classes are
compiled.
Comments
Thanks Jamsheed! I'll see if I can find out what may have changed.
29-11-2016
it is not failing now [~dholmes] . seems like something changed !
28-11-2016
I can not reproduce any crashes on the odroid system with this "fix" removed. Jamsheed: can you give me the exact steps you used to always get the crash please.
24-11-2016
i tried with one random test, .. harness always fail.. one that i tried was test/compiler/jsr292/NullConstantReceiver.java
16-11-2016
I regressed the change but was unable to provoke any failures on the listed system. Was there a specific jtreg test that failed or was it "random"?
16-11-2016
I realize that this is not the fix for the problem but since it appears to solve our crashes on more than one ARMv7 device, I think the change is worth integrating until someone can take a look at both the AARCH64 and ARMv7 problems caused by or triggered by the quick_enter logic. As I mentioned in the description above, I tried several options to alter timing in order to determine if this issue was a race condition in the C2 code generation without success. I was able to reproduce this issue even with a slow debug build.
28-10-2016
I was responding to Bob.
27-10-2016
David, I'm not sure who you are responding to, but... I agree that this is a problem with AARCH64 (or ARM) C2 code and I think I stated that quite clearly. I also stated quite clearly that this is not a fix. The fix will be done via: JDK-8153107 enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs
25-10-2016
I still contend that this is a C2 issue if you can only reproduce it with C2! The quick_enter optimization does not involve platform specific code, so if it doesn't seem to work then the bug lies in the existing code. Disabling the optimization should be considered a short-term workaround, not a fix.
25-10-2016
The above change avoids using the quick_enter() optimization. It is not a fix for whatever problem exists with that optimization and AARCH64 (or ARM) C2 code.
24-10-2016
As stated in https://bugs.openjdk.java.net/browse/JDK-8153107, "ARM64 was never a target platform for the Contended Locking project. While this bug might get addressed in the JDK9 time frame, I currently have no plans to do so." Since Dan stated that ARM64 is not a target for this feature, I suspect 32 bit ARM is even lower on the supported priority list. I think we should just disable this feature for ARM.
24-10-2016
As per email that change may simply avoid the problem rather than fix it. There was no reason to disable ARM because no problems were seen on ARM and the original changes did not involve CPU specific code. If this is C2 specific then the problem likely lies somewhere in the C2 generated code.
21-10-2016
The fix for https://bugs.openjdk.java.net/browse/JDK-8077392 disabled quick_enter on AARCH64 platforms. This fix should have also been applied to ARM platforms. Applying this patch appears to have solved the crashes running jtreg. diff --git a/src/share/vm/runtime/sharedRuntime.cpp b/src/share/vm/runtime/sharedRuntime.cpp --- a/src/share/vm/runtime/sharedRuntime.cpp +++ b/src/share/vm/runtime/sharedRuntime.cpp @@ -1984,7 +1984,9 @@ JRT_BLOCK_ENTRY(void, SharedRuntime::complete_monitor_locking_C(oopDesc* _obj, BasicLock* lock, JavaThread* thread)) // Disable ObjectSynchronizer::quick_enter() in default config // on AARCH64 until JDK-8153107 is resolved. - if (AARCH64_ONLY((SyncFlags & 256) != 0 &&) !SafepointSynchronize::is_synchronizing()) { + if (ARM_ONLY((SyncFlags & 256) != 0 &&) + AARCH64_ONLY((SyncFlags & 256) != 0 &&) + !SafepointSynchronize::is_synchronizing()) { // Only try quick_enter() if we're not trying to reach a safepoint // so that the calling thread reaches the safepoint more quickly. if (ObjectSynchronizer::quick_enter(_obj, thread, lock)) return;
20-10-2016
Sure, Tobias.
14-10-2016
Thanks, Bob! [~jcm], could you please have a look? I was able to reproduce the bug on the system mentioned by Bob.
14-10-2016
This failure occurs even with the latest JDK 9 hotspot closed ARM sources. Here are the sources to the open ARM port. http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264 I have a workspace on bussund0416.us.oracle.com:/export/users/bobv/jdk9-arm3264 The binaries are in the /export/users/bobv/jdk9-arm3264/build/b00/* I built a slowdebug image here: bussund0416.us.oracle.com:/export/users/bobv/jdk9-arm3264/build/b00/linux-arm-slowdebug
13-10-2016