On Mon, 8 Jun 2026 18:50:44 GMT, Alan Bateman <[email protected]> wrote:
> As always then touching the debugger protocol is to know what the behavior is
> when the target VM is an older release and doesn't support the
> INVOKE_DISABLE_COLLECTION option. If it's not an error already then it might
> require a tool-side check so that invokeMethod and newInstance throws if the
> target VM is < 28.
There are no checks of the invoke options passed in JDI or the debug agent to
make sure the option is recognized, which kind of surprised me. So older
versions of the debug agent and JDI are just going to ignore any use of
INVOKE_DISABLE_COLLECTION. This can be a bit problematic if there is a JDI /
debug agent version mismatch when JDI recognizes INVOKE_DISABLE_COLLECTION but
the debug agent does not. JDI will do the increment of gcDisableCount in this
case even though the object has not been pinned by the debug agent. The JDI
client probably is not doing an explicit ObjectReference.disableCollection()
because it expects that it has already been implicitly done, but even if it did
one anyway, it would not result in JDWP ObjectReference.DisableCollection
because gcDisableCount == 1:
public synchronized void disableCollection() {
if (gcDisableCount == 0) {
try {
JDWP.ObjectReference.DisableCollection.process(vm, this);
} catch (JDWPException exc) {
throw exc.toJDIException();
}
}
gcDisableCount++;
}
Is this an appropriate situation for adding a new VirtualMachine.canXXX
capability check in JDI and JDWP, or should a JVM version check be done
instead. In any case, JDI should not increment gcDisableCount if the debug
agent does not support INVOKE_DISABLE_COLLECTION, and debuggers should do an
explicit disableCollection() if INVOKE_DISABLE_COLLECTION is not supported.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/31421#issuecomment-4652523597
