JDK-7112085 : assert(fr.interpreter_frame_expression_stack_size()==0) failed: only handle empty stacks
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8-pool
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-11-15
  • Updated: 2013-04-24
  • Resolved: 2012-01-20
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 7 JDK 8 Other
7u4Fixed 8Fixed hs23Fixed
Related Reports
Relates :  
JDK-7096639 - Tiered: Incorrect counter overflow handling for inlined methods
Description
A lot Nightly tests with -XX:+DeoptimizeALot start failing after 7096639 changes:

#  Internal Error (src/share/vm/runtime/sharedRuntime.cpp:2863), pid=22165, tid=21
#  assert(fr.interpreter_frame_expression_stack_size()==0) failed: only handle empty stacks
#


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

Current thread (0x08363400):  JavaThread "MainThread" [_thread_in_Java, id=21, stack(0xb1427000,0xb1477000)]

Stack: [0xb1427000,0xb1477000],  sp=0xb14756c0,  free space=313k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1dfb754]  void VMError::report(outputStream*)+0x904
V  [libjvm.so+0x1dfc905]  void VMError::report_and_die()+0x56d
V  [libjvm.so+0xb4e84a]  void report_vm_error(const char*,int,const char*,const char*)+0x53a
V  [libjvm.so+0x1b77272]  int*SharedRuntime::OSR_migration_begin(JavaThread*)+0x6a6
j  Test6905845.main([Ljava/lang/String;)V+131
v  ~StubRoutines::call_stub
V  [libjvm.so+0xfc6180]  void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x8a8
V  [libjvm.so+0x196aa00]  void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x18
V  [libjvm.so+0xfc589c]  void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*)+0x44
V  [libjvm.so+0x1aeeb44]  oop Reflection::invoke(instanceKlassHandle,methodHandle,Handle,bool,objArrayHandle,BasicType,objArrayHandle,bool,Thread*)+0x2e20
V  [libjvm.so+0x1af0fbb]  oop Reflection::invoke_method(oop,Handle,objArrayHandle,Thread*)+0x8ef
V  [libjvm.so+0x1292de5]  JVM_InvokeMethod+0x8dd
C  [libjava.so+0x1551f]  Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x27
j  sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j  sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
j  sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+57
j  com.sun.javatest.regtest.MainWrapper$MainThread.run()V+60
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub
V  [libjvm.so+0xfc6180]  void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x8a8
V  [libjvm.so+0x196aa00]  void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x18
V  [libjvm.so+0xfc3e04]  void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,Symbol*,Symbol*,Thread*)+0x458
V  [libjvm.so+0x125cc52]  void thread_entry(JavaThread*,Thread*)+0x266
V  [libjvm.so+0x1cee497]  void JavaThread::thread_main_inner()+0x4bb
V  [libjvm.so+0x1cede05]  void JavaThread::run()+0x619
V  [libjvm.so+0x195a293]  java_start+0x6fb
C  [libc.so.1+0xbd673]  _thrp_setup+0x9b
C  [libc.so.1+0xbd920]  _lwp_start+0x0

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  Test6905845.main([Ljava/lang/String;)V+131
v  ~StubRoutines::call_stub
j  sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j  sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
j  sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+57
j  com.sun.javatest.regtest.MainWrapper$MainThread.run()V+60
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub
Comments
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/973293defacd
22-03-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/973293defacd
15-12-2011
EVALUATION The runtime call to the policy from the inlinee invocation had an incorrect jvm state. As a result the bytecode preceding the invoke of the inlinee was executed twice in case we deoptimized. Since it's currently not quite easy to set the reexecute flag in C1, I moved the notification call into the preamble of the inlinee so that I could use InvocationEntryBci in the state specification, which would deopt correctly. Also made some minor changes to printing of tiered events. Webrev: http://cr.openjdk.java.net/~iveresov/7112085/webrev.00/
22-11-2011