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
