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

Daniel D.Daugherty dcubed at openjdk.java.net
Wed Sep 23 21:33:00 UTC 2020


On Wed, 23 Sep 2020 21:22:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> No jni_enter(). Just jni_exit(). We are trying to provoke an unbalanced
>> monitorexit() here.
>
> 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...

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

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


More information about the hotspot-runtime-dev mailing list