JDK-8195979 : [Graal] crash in src/hotspot/share/runtime/mutex.cpp:1341 when Graal JIT is used
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2018-01-23
  • Updated: 2020-09-01
  • Resolved: 2018-01-24
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 11
11 b01Fixed
Related Reports
Relates :  
JDK-8194312 - Support parallel and concurrent JNI global handle processing
Relates :  
JDK-8196083 - Avoid locking in OopStorage::release
Description
Graal unit tests crashes with

#  Internal Error (/home/katya/work/JavaSE/Hotspot/ws/jdk.hs/open/src/hotspot/share/runtime/mutex.cpp:1341), pid=14825, tid=14886
#  fatal error: acquiring lock JNIWeakAlloc_lock/18 out of order with lock Patching_lock/3 -- possible deadlock
#
Comments
ILW = Crash due to possible deadlock (integration blocker), many tests with Graal, don't use Graal as JIT = HMM = P2
24-01-2018
I'm testing a temporary fix, to unblock testing; RFR later today, I think. I'm also working on a real fix, but it will take a bit longer.
24-01-2018
Yes this is a recent regression caused by JDK-8194312: Support parallel and concurrent JNI global handle processing
24-01-2018
Thanks for the simple reproducer. It doesn't fail every time, but often enough to be very useful.
24-01-2018
Actually quite a lot of tests crash the same way, not only graal tests. One of them which is very easy to reproduce is compiler/escapeAnalysis/Test6775880.java Steps to reproduce: > jtreg -timeout:5 -vt -k:\!ignore -jdk:HS_FASTDEBUG -dir:test/hotspot/jtreg -javaoptions:"-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal" compiler/escapeAnalysis/Test6775880.java Note, no failure if Graal jit is not used (-XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal)
23-01-2018
Destroying a global (strong or weak) handle may now sometimes take a lock, where it previously didn't (and so was instead at risk of crashing, at least in debug builds). I'd considered lowering the rank of the JNI locks, but hadn't found (either through testing or inspection) a place where it mattered. Looks like I missed one (at least) though. I think such lowering is the right solution though; only question is to what. The Patching_lock rank is "special", which is *extremely* low (3).
23-01-2018
Looks like fallout from the OopStorage changes - so added ~kbarrett to watchers.
23-01-2018
hs_err is attached
23-01-2018