JDK-6775880 : EA +DeoptimizeALot: assert(mon_info->owner()->is_locked(),"object must be locked now")
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs14
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2008-11-25
  • Updated: 2012-02-01
  • Resolved: 2008-12-10
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 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Description
Affect both 32- and 64-bits VM.

Could be the same problem in Nightly failed test :
nsk/stress/jck12a/jck12a016

% /java/re/jdk/7/latest/binaries/solaris-amd64/fastdebug/bin/java -d64 -XX:+DeoptimizeALot  -XX:+DoEscapeAnalysis -Xss4m -Xverify:all  -XX:+CompileTheWorld -Xbootclasspath/p:/net/vmsqe.sfbay/export/backup/testbase/CompileTheWorld/jarfiles/IBMJCEProvider.jar 
...

CompileTheWorld (301) : com/ibm/security/x509/NoticeReference
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/deoptimization.cpp:830
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/BUILD_AREA/jdk7.0/hotspot/src/share/vm/runtime/deoptimization.cpp:830), pid=1338, tid=2
#  Error: assert(mon_info->owner()->is_locked(),"object must be locked now")
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (14.0-b07-fastdebug mixed mode solaris-amd64 )
# An error report file with more information is saved as:
# /export/kvn/ctw/multictw.i586/hs_err_pid1338.log
#

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) 
V  [libjvm.so+0xf5a5ac] void VMError::report(outputStream*) + 0xdfc
V  [libjvm.so+0xf5bb0d] void VMError::report_and_die() + 0x8bd
V  [libjvm.so+0x8bcd62] void report_assertion_failure(const char*,int,const char*) + 0x82
V  [libjvm.so+0x8cece2] void Deoptimization::relock_objects(GrowableArray<MonitorInfo*>*,JavaThread*) + 0x252
V  [libjvm.so+0x8cc0fa] Deoptimization::UnrollBlock*Deoptimization::fetch_unroll_info_helper(JavaThread*) + 0x79a
V  [libjvm.so+0x8cb93c] Deoptimization::UnrollBlock*Deoptimization::fetch_unroll_info(JavaThread*) + 0x16c
v  ~DeoptimizationBlob 
 
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) 
v  ~DeoptimizationBlob 
J  com.ibm.security.util.ObjectIdentifier.toString()Ljava/lang/String; 
J  com.ibm.security.util.ObjectIdentifier.hashCode()I 
j  java.util.Hashtable.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+18 
j  com.ibm.security.x509.OIDMap.loadNames()V+62 
j  com.ibm.security.x509.OIDMap.<clinit>()V+36 
v  ~StubRoutines::call_stub

Comments
SUGGESTED FIX Problem: Locks elimination for non-escaping objects incorrectly assumes that different objects have different BoxLock nodes. It is not true, BoxLock could be shared for locking different objects. As result "eliminated" status of BoxLock node is incorrect when locks for one object were eliminated and for an other they were not. This affects debug info and leads to the assert during deoptimization. Solution: - ConnectionGraph::escape_state(n, phase) should return the state of JavaObject. - Use EA information during all optimizations since optimizations can not change the escape state to worse but they can change the lock's obj_node input to non-escaping one which will allow to eliminate the lock (for example, after parser the obj_node is a phi which points to an incoming parameter and non-escaping allocation, and during optimizations the parameter path became dead). - Create new "eliminated" BoxLock node and use it in monitor debug info when corresponding locks are eliminated. - Add the check "eliminated" status to BoxLock node's hash() and cmp() methods to distinguish such nodes. - Also delete FastLock node when the lock code is removed from graph.
04-12-2008

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/424f9bfe6b96
04-12-2008