JDK-6862370 : c1 assert(false,"Non-balanced monitor enter/exit!") with -XX:-UseFastLocking -Xcomp
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs16
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2009-07-20
  • Updated: 2011-02-17
  • Resolved: 2011-02-17
Related Reports
Duplicate :  
JDK-6840152 - JVM crashes when heavyweight monitors are used
Relates :  
JDK-6648715 - assert(false,"Non-balanced monitor enter/exit!")
Description
With -XX:-UseBiasedLocking Queens runs.
jvmg build on x86 solaris.
I was using -XX:-UseFastLocking to try to debug some other problem, not sure if you can produce this otherwise.

% gamma -Xcomp -XX:-UseFastLocking Queens
VM option '-UseFastLocking'
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/synchronizer.cpp:3440
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/net/philli/scratch1/coleenp/hg/6859079/src/share/vm/runtime/synchronizer.cpp:3440), pid=4226, tid=1
#  Error: assert(false,"Non-balanced monitor enter/exit!")
#
# JRE version: 7.0-b45
# Java VM: Java HotSpot(TM) Client VM (16.0-b04-6859079_0720_1530-jvmg compiled mode solaris-x86 )
# An error report file with more information is saved as:
# /net/philli/scratch1/coleenp/hg/6859079/make/solaris/solaris_i486_compiler1/jvmg/hs_err_pid4226.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Current thread is 1
Dumping core ...
Abort
ruger%

hs_err file attached.
Comments
EVALUATION 6840152: JVM crashes when heavyweight monitors are used Summary: Turn off biased locking if !UseFastLocking or UseHeavyMonitors options are requested. Reviewed-by: phh, never, dcubed, dholmes Fixed this too.
17-02-2011
SUGGESTED FIX --- old/src/share/vm/c1/c1_Runtime1.cpp Mon Jul 27 15:42:25 2009 +++ new/src/share/vm/c1/c1_Runtime1.cpp Mon Jul 27 15:42:24 2009 @@ -753,6 +753,7 @@ Handle h_obj(thread, obj); assert(h_obj()->is_oop(), "must be NULL or an object"); if (UseBiasedLocking) { + if (!UseFastLocking) lock->set_obj(obj); // Retry fast entry if bias is revoked to avoid unnecessary inflation ObjectSynchronizer::fast_enter(h_obj, lock->lock(), true, CHECK); } else { This didn't actually fix it but it prevented another assertion because obj isn't initialized.
27-07-2009