JDK-7196242 : JSR 292: vm/mlvm/indy/stress/java/loopsAndThreads crashed
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs24,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-09-05
  • Updated: 2014-03-20
  • Resolved: 2012-09-11
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 7 JDK 8 Other
7u40Fixed 8Fixed hs24Fixed
Description
This test
vm/mlvm/indy/stress/java/loopsAndThreads
fails with crash on client compiller.

See aurora test hisory:
http://vmsqe-app.russia.sun.com/surl/LE

Comments
hsdev-15:~$ java -showversion -client -Xcomp -XX:DefaultMaxRAMFraction=8 -XX:-TieredCompilation -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions -XX:+DeoptimizeALot -cp $VM8TESTBASE vm.mlvm.indy.stress.java.loopsAndThreads.INDIFY_Test -stressIterationsFactor 10 -stressThreadsFactor 100 java version "1.7.0-internal" Java(TM) SE Runtime Environment (build 1.7.0-internal-201210200753.jcoomes.hs24-b23-jdk7u12-b0-b00) Java HotSpot(TM) Client VM (build 24.0-b24-internal-fastdebug, compiled mode) Stress time: 60 seconds Stress iterations factor: 10 Stress threads factor: 100 Locks owned: Mutex: [0x8069728/0x1] Patching_lock - owner: 0x8837000 # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/mutex.cpp:1321 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/cthaling/hsx24/src/share/vm/runtime/mutex.cpp:1321), pid=7908, tid=93 # fatal error: acquiring lock Threads_lock/15 out of order with lock Patching_lock/1 -- possible deadlock # # JRE version: Java(TM) SE Runtime Environment (7.0) # Java VM: Java HotSpot(TM) Client VM (24.0-b24-internal-fastdebug compiled mode solaris-x86 ) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/cthaling/jdk/test/java/lang/invoke/6998541/hs_err_pid7908.log Locks owned: Mutex: [0x8069728/0x1] Patching_lock - owner: 0x8837000 # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Current thread is 93 Dumping core ... Abort
25-10-2012

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4bfe8b33cf66
15-09-2012

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4bfe8b33cf66
11-09-2012

EVALUATION The current code in ConstantPoolCacheEntry::set_method_handle_common uses a CAS to find out who's the winning thread in the race about linking an invokehandle/invokedynamic call site. The winning thread does the linking while the other threads are waiting in a loop until the winning thread finishes. The waiting threads enter the Patching_lock and call os::yield to give the winning thread more CPU time. Unfortunately the implementation of os::yield on Solaris uses the Threads_lock and we hit this assert: # fatal error: acquiring lock Threads_lock/15 out of order with lock Patching_lock/1 -- possible deadlock Even worse, the CAS might fail spuriously and we don't have a winning thread because we don't loop around the CAS. This may lead to hangs.
10-09-2012

EVALUATION This assert: # fatal error: acquiring lock Threads_lock/15 out of order with lock Patching_lock/1 -- possible deadlock is a known issue and we have a fix for that. The other issue: # JRE version: Java(TM) SE Embedded Runtime Environment (8.0-b53) # Java VM: Java HotSpot(TM) Embedded Client VM (24.0-b21-internal-201208301813.cphillim.emb-sa-fastdebug compiled mode linux-ppc ) # Problematic frame: # C [libc.so.6+0x8e1f8] memset+0x2b4 is probably unrelated and we should file a separate bug for it.
10-09-2012