United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7196242 JSR 292: vm/mlvm/indy/stress/java/loopsAndThreads crashed
JDK-7196242 : JSR 292: vm/mlvm/indy/stress/java/loopsAndThreads crashed

Details
Type:
Bug
Submit Date:
2012-09-05
Status:
Resolved
Updated Date:
2013-04-30
Project Name:
JDK
Resolved Date:
2012-09-11
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs24,8
Fixed Versions:
hs25 (team)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Duplicate:

Sub Tasks

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
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.
                                     
2012-09-10
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.
                                     
2012-09-10
EVALUATION

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

http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4bfe8b33cf66
                                     
2012-09-15
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

                                     
2012-10-25



Hardware and Software, Engineered to Work Together