RFR(s): 8247248: JVM TI might create JNI locals in another thread when using handshakes.

[David Holmes]

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