Hi Robbin,

On 10/06/2020 2:15 am, Robbin Ehn wrote:
Hi all,

If the direct handshake is executed by the target thread, the JNI
local(s) are created in that thread but returned in the handshaking
thread.
They thus are not safe to use. (thread might even have exited by this
point)

Code:
http://cr.openjdk.java.net/~rehn/8247248/v1/webrev/

Unfortunately there is no way the distinguish a local jobject vs a
global. Which makes it hard to track when the jobject is global and not.

I have some comments/concerns that I've added to the bug report.

Switching from local refs to global refs adds a bit of overhead and will likely impact the performance here. Not a showstopper but would be nice to avoid if possible as it seems a bit of a kludge to communicate values across threads via global refs.

In the old VMOperation solution the VMThread used the JvmtiEnv* of the calling thread so that the local refs were in the right place. Can we do the same with the handshake code? It will mean restoring the "calling thread" argument to the handshake operation but I think this is a workable approach. (The removal of the calling thread argument should have rung alarm bells :( .)

Or, could this be case where we don't want the target thread to execute the handshake and we need a way to mark the handshake operation as such? That's a bigger change of course.

Thanks,
David
-----

Issue:
https://bugs.openjdk.java.net/browse/JDK-8247248

Local testing of JDI/JVMTI and t1-5.
(no real crash so there is nothing to reproduce)

Thanks, Robbin

Reply via email to