RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function

[Daniel D.Daugherty]

On Wed, 23 Sep 2020 18:08:50 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/interpreter/interpreterRuntime.cpp line 746:
>> 
>>> 744:   if (elem == NULL || h_obj()->is_unlocked()) {
>>> 745:     THROW(vmSymbols::java_lang_IllegalMonitorStateException());
>>> 746:   }
>> 
>> In the case of an unbalanced monitorexit(), you are losing
>> the throwing of the IllegalMonitorStateException here.
>> At one point, we had at least one test that used JNI MonitorExit()
>> to induce an unbalanced monitorexit() and it verified that the
>> IllegalMonitorStateException was thrown.
>
> But JNI MonitorExit() calls ObjectSynchronizer::jni_exit() instead and that calls check_owner() which will throw
> java_lang_IllegalMonitorStateException() if the thread is not the owner. I agree we might still need to throw
> java_lang_IllegalMonitorStateException() here for the release bits though. Maybe we still need to cover the case of the
> classfile having wrong bytecodes and there is an extra monitorexit?

The JNI MonitorExit() call will succeed because the calling thread is
the owner of the monitor. The subsequent monitorexit byte code
should fail because the calling thread is no longer the owner of
the monitor. It's a way of simulating an errant situation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/320