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