United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6805748 Assertion "don't reset to 0 -- could be mistaken for never-executed" in CompilationPolicy
JDK-6805748 : Assertion "don't reset to 0 -- could be mistaken for never-executed" in CompilationPolicy

Details
Type:
Bug
Submit Date:
2009-02-15
Status:
Closed
Updated Date:
2012-02-01
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
generic
Sub-Component:
runtime
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs14
Fixed Versions:
hs15 (b04)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

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

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.
                                     
2009-03-19
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);
 }
                                     
2009-03-19
WORK AROUND

Use -XX:CompileThreshold=2 as a workaround.
                                     
2009-03-19
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c664a0794f85
                                     
2009-03-21



Hardware and Software, Engineered to Work Together