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

[Coleen Phillimore]

On Wed, 23 Sep 2020 21:28:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Yes, it looks like you can break this with JNI code with and extra jni_exit() for the object, and then call the
>> monitorexit from the interpreter.  This interpreter change is to be consistent with the compiled code that calls via
>> JRT_LEAF, so compiled code would have the same problem. I can add a fatal to this like: fatal(obj->is_locked(), "Native
>> code may have unlocked this object"); fatal() would assert in product mode, and errant native code can expect crashes
>> even in product mode. elem would never be null since it's allocated in the caller.
>
> I think you mean assert(obj->is_locked(), "this object must be locked") since fatal() doesn't take a bool...

> Maybe we still need to cover the case of the classfile having wrong bytecodes and there is an extra monitorexit?
The checks before the calls to unlock_object() handle this case.

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

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