RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized

Roland Westrelin rwestrel at redhat.com
Thu Jun 2 08:56:23 UTC 2016


>>>> So given uncommon traps are unaffected and only deopts are, isn't the
>>>> change below good enough?
>>> uncommon traps are affected in  JVMCI case. pending exception check is
>>> after jvmci lock code.
>> That code in TemplateInterpreterGenerator::generate_deopt_entry_for()?
>>
>> #if INCLUDE_JVMCI
>>    // Check if we need to take lock at entry of synchronized method.
>>    if (UseJVMCICompiler) {
>>      Label L;
>>      __ cmpb(Address(thread, JavaThread::pending_monitorenter_offset()), 0);
>>      __ jcc(Assembler::zero, L);
>>      // Clear flag.
>>      __ movb(Address(thread, JavaThread::pending_monitorenter_offset()), 0);
>>      // Satisfy calling convention for lock_method().
>>      __ get_method(rbx);
>>      // Take lock.
>>      lock_method();
>>      __ bind(L);
>>    }
>> #endif
> Yes.

Can't we simply clear pending_monitorenter, for instance in
Deoptimization::pop_frames_failed_reallocs?

Roland.


diff --git a/src/share/vm/runtime/deoptimization.cpp b/src/share/vm/runtime/deoptimization.cpp
--- a/src/share/vm/runtime/deoptimization.cpp
+++ b/src/share/vm/runtime/deoptimization.cpp
@@ -497,6 +497,12 @@
     exec_mode = Unpack_exception;
   }
 #endif
+  if (thread->frames_to_pop_failed_realloc() > 0) {
+    assert(thread->has_pending_exception(), "should have thrown OOME");
+    thread->set_exception_oop(thread->pending_exception());
+    thread->clear_pending_exception();
+    exec_mode = Unpack_exception;
+  }
 
   UnrollBlock* info = new UnrollBlock(array->frame_size() * BytesPerWord,
                                       caller_adjustment * BytesPerWord,
@@ -1228,6 +1234,7 @@
 #endif
     }
   }
+  thread->set_pending_monitorenter(false);
 }
 #endif
 


More information about the hotspot-compiler-dev mailing list