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.
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
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.