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
