JDK-6805748 : Assertion "don't reset to 0 -- could be mistaken for never-executed" in CompilationPolicy
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs14
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-02-15
  • Updated: 2012-02-01
  • Resolved: 2011-03-08
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
6u18Fixed 7Fixed hs15Fixed
Related Reports
Relates :  
JDK-7115356 - assert(!m->was_never_executed()) failed
Description
Fastdebug jvm launched with "-Xcomp -XX:CompileThreshold=1" flags
intermittently fails with

#  Internal Error (/BUILD_AREA/jdk7/hotspot/src/share/vm/runtime/compilationPolicy.cpp:104), pid=24735, t
id=2931739536
#  Error: assert(!m->was_never_executed(),"don't reset to 0 -- could be mistaken for never-executed")
#

# JRE version: 7.0-b47
# Java VM: Java HotSpot(TM) Server VM (15.0-b01-fastdebug compiled mode linux-x86 )
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0xae905000):  JavaThread "Loading Thread #1" [_thread_in_vm, id=24850, stack(0xaeb9c000,0
xaebed000)]

Stack: [0xaeb9c000,0xaebed000],  sp=0xaebeb458,  free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xaca378];;  VMError::report_and_die()+0x2f8
V  [libjvm.so+0x4939b5];;  report_assertion_failure(char const*, int, char const*)+0x65
V  [libjvm.so+0x41f326];;  CompilationPolicy::reset_counter_for_invocation_event(methodHandle)+0x76
V  [libjvm.so+0x41f503];;  SimpleCompPolicy::method_invocation_event(methodHandle, Thread*)+0x53
V  [libjvm.so+0x5e0042];;  InterpreterRuntime::frequency_counter_overflow(JavaThread*, unsigned char*)+0x
492
j  javasoft.sqe.jck.lib.vm.resolveClass.hierarchies.init.dynamic.anonymous.simple.A4.<init>()V+0
j  javasoft.sqe.jck.lib.vm.resolveClass.hierarchies.init.dynamic.anonymous.simple.B$4.<init>(Ljavasoft/sq
e/jck/lib/vm/resolveClass/hierarchies/init/dynamic/anonymous/simple/B;)V+6
j  javasoft.sqe.jck.lib.vm.resolveClass.hierarchies.init.dynamic.anonymous.simple.B.<init>()V+36
J  javasoft.sqe.jck.lib.vm.resolveClass.hierarchies.init.dynamic.anonymous.simple.C1.<init>()V
V  [libjvm.so+0x5ebb21];;  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)
+0x2b1
V  [libjvm.so+0x8deab8];;  os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments
*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x18
V  [libjvm.so+0x5eb830];;  JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x40
V  [libjvm.so+0x97d486];;  Reflection::invoke(instanceKlassHandle, methodHandle, Handle, bool, objArrayHa
ndle, BasicType, objArrayHandle, bool, Thread*)+0xa06
V  [libjvm.so+0x983ed1];;  Reflection::invoke_constructor(oopDesc*, objArrayHandle, Thread*)+0x291
V  [libjvm.so+0x6c2141];;  JVM_NewInstanceFromConstructor+0x1d1
C  [libjava.so+0x1534d]  Java_sun_reflect_NativeConstructorAccessorImpl_newInstance0+0x2d;;  Java_sun_ref
lect_NativeConstructorAccessorImpl_newInstance0+0x2d
J  sun.reflect.NativeConstructorAccessorImpl.newInstance0(Ljava/lang/reflect/Constructor;[Ljava/lang/Obje
ct;)Ljava/lang/Object;

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  javasoft.sqe.jck.lib.vm.resolveClass.hierarchies.init.dynamic.anonymous.simple.A4.<init>()V+0
j  javasoft.sqe.jck.lib.vm.resolveClass.hierarchies.init.dynamic.anonymous.simple.B$4.<init>(Ljavasoft/sq
e/jck/lib/vm/resolveClass/hierarchies/init/dynamic/anonymous/simple/B;)V+6
j  javasoft.sqe.jck.lib.vm.resolveClass.hierarchies.init.dynamic.anonymous.simple.B.<init>()V+36
J  javasoft.sqe.jck.lib.vm.resolveClass.hierarchies.init.dynamic.anonymous.simple.C1.<init>()V
v  ~StubRoutines::call_stub
J  sun.reflect.NativeConstructorAccessorImpl.newInstance0(Ljava/lang/reflect/Constructor;[Ljava/lang/Obje
ct;)Ljava/lang/Object;
J  sun.reflect.NativeConstructorAccessorImpl.newInstance([Ljava/lang/Object;)Ljava/lang/Object;
J  sun.reflect.DelegatingConstructorAccessorImpl.newInstance([Ljava/lang/Object;)Ljava/lang/Object;
J  java.lang.reflect.Constructor.newInstance([Ljava/lang/Object;)Ljava/lang/Object;
J  java.lang.Class.newInstance0()Ljava/lang/Object;
J  java.lang.Class.newInstance()Ljava/lang/Object;
J  javasoft.sqe.jck.lib.vm.resolveClass.parallelClassLoading.ClassLoadingThread.run()V
v  ~StubRoutines::call_stub
A sighting in nightly testing:

New MM_REGRESSION failures (from 2009.02.24)
*   java/lang/management/ThreadMXBean/ThreadCpuTime.java
        This test failed the following assert:

            Internal Error (src/share/vm/runtime/compilationPolicy.cpp:104)
            Error: assert(!m->was_never_executed(),
                "don't reset to 0 -- could be mistaken for never-executed")

        on Win-AMD64 Server VM -Xmixed (machine intelsdv14). This is an
        occurrence of the following bug:

            6805748 2/2 Assertion "don't reset to 0 -- could be
                        mistaken for never-executed" in CompilationPolicy

        I will copy this entry to 6805748.

Links to the analysis page and the hs_err_pid file:

http://sqeweb.sfbay/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2009-02-24/RT_Baseline/javase/windows-amd64/server/mixed/windows-amd64_server_mixed_MM_REGRESSION/analysis.html
http://sqeweb.sfbay/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2009-02-24/RT_Baseline/javase/windows-amd64/server/mixed/windows-amd64_server_mixed_MM_REGRESSION/workDir/java/lang/management/ThreadMXBean/ThreadCpuTime/hs_err_pid246240.log
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c664a0794f85
21-03-2009
WORK AROUND Use -XX:CompileThreshold=2 as a workaround.
19-03-2009
SUGGESTED FIX --- old/src/share/vm/interpreter/invocationCounter.cpp Thu Mar 19 15:04:04 2009 +++ new/src/share/vm/interpreter/invocationCounter.cpp Thu Mar 19 15:04:03 2009 @@ -47,6 +47,8 @@ // executed many more times before re-entering the VM. int old_count = count(); int new_count = MIN2(old_count, (int) (CompileThreshold / 2)); + // prevent from going to zero, to distinguish from never-executed methods + if (new_count == 0) new_count = 1; if (old_count != new_count) set(state(), new_count); }
19-03-2009
EVALUATION This stress flag causes the assertion. With CompileThreshold=1, the method's invocation counter is reset to CompileThreshold/2 = 0. The carry bit is also set and is supposed to indicate that it has been executed, even when the count goes to zero. But there's a race where the 'carry' bit of the invocation counter is reset to zero and then set again at the point of the assert. I've looked through the C++ compiler generated code for the race that is causing this and found some in the interpreters when incrementing the invocation count, but this test still doesn't pass with the fix to this interpreter race. I can't find what's resetting the carry bit! In the InvocationCounter code there are conditionals that protect the count from going to zero, in other cases, and adding it to set_carry() fixes the bug. It's also less code disturbed than adding volatile to all the invocationCounter methods for this special case of CompilationThreshold=1.
19-03-2009