RFC: 8229160: Reimplement JvmtiRawMonitor to use PlatformMonitor
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Mon Sep 9 23:11:49 UTC 2019
Hi David,
On 9/9/19 15:49, David Holmes wrote:
> Hi Serguei,
. . .
>>
>> The JDWP implementation is using RawMonitor's.
>> Please, see functions debugMonitorWait()/debugMonitorTimedWait() in
>> src/jdk.jdwp.agent/share/native/libjdwp/util.c.
>>
>> It expects the JVMTI_ERROR_INTERRUPT but never makes a call to the
>> JVMTI ThreadInterrupt().
>> So, it looks like it does not depend on interrupting of RawMonitor's
>> in any way.
>>
>>>
>>> The more I try to convince people this change should be okay, the
>>> more uncomfortable I get with my own arguments. :) I think I'm going
>>> to implement the polling approach for checking interrupts - say 500ms.
>>
>> The JVMTI spec tells that the JVMTI_ERROR_INTERRUPT can be returned
>> from the RawMonitorWait:
>> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#RawMonitorWait
>>
>
> Yes it does and that is the only thing that implies a connection to
> Thread.interrupt.
>
>> which means that RawMonitorWait can be interrupted with the
>> Thread.Interrupt()
>> or JVMTI InterruptThread():
>> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#InterruptThread
>>
>
> That's one way to interpret the fact that RawMonitorWait can return
> JVMTI_ERROR_INTERRUPT, but the actual interaction between
> Thread.interrupt and RawMonitorWait is not explicitly stated.
Yes, it is true.
The same is true about the actual interaction with the JVMTI
InterruptThread().
But it seems, this function is expected to actually interrupt waiting on
a RawMonitorWait() call or any other wait() calls.
> Arguably you can just check for interruption before and after the
> wait, to see whether to return JVMTI_ERROR_INTERRUPT, without
> necessarily being able to break out of the wait itself. That's been
> the whole premise of this change proposal - that responsiveness to
> interrupts is more a quality-of-implementation issue.
Right, it is another way to interpret it.
>
> But in any case I've decided to try the polling approach so that we
> won't wait forever if interrupted but not notified.
It sounds better.
Thanks,
Serguei
>
> Thanks,
> David
> -----
>
>> Thanks,
>> Serguei
More information about the serviceability-dev
mailing list