RFR(s): 8247248: JVM TI might create JNI locals in another thread when using handshakes.
Robbin Ehn
robbin.ehn at oracle.com
Wed Jun 10 07:55:15 UTC 2020
Hi David,
On 2020-06-10 04:30, David Holmes wrote:
> 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.
Using our test to measure nanos, it's seem to be 5%, 21 us to 22 us when
target is current thread, no handshake at all.
(handshake case is around 65 us, so noise is larger than overhead).
In earlier version of the patch I skipped global when doing thread self.
But since it's not easy to track if it's a global or local I removed
that for the simplification.
>
> 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.
This is a good idea, and we can easily implement a generic facility in
the, hopefully, upcoming asynchronous handshakes.
But no matter in what form I don't see us getting this enhancement to
handshakes before JDK 15.
How do you want to proceed for JDK 15?
Thanks, Robbin
>
> 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
More information about the serviceability-dev
mailing list