On 27/05/2019 15:33, Langer, Christoph wrote:
:
The principal feature here is that one wants to be able to "debug on demand". Currently
(or before the change that we're discussing was implemented) one had to start the JVM with the JDWP
agent activated in case one's planning to debug. The "onjcmd" option gives the
possibility to start the JDWP agent in a standby mode and later on activate the actual debugging.
The most common way will probably be to use jcmd but there are also other ways using MXBeans to
trigger the debugging. So I don't see the tie to a certain JDK-specific tool here.
I think the overall story of "debugging on demand" is quite compelling. We've
had that for years in SAP's proprietary JVM and it was well received by the users. It
gives you the option to connect with the debugger post mortem to analyze issues.
"debugging on demand" is a big topic. It would certainly be compelling
to allow a developer connect a debugger to a running VM when that VM was
not initially started with the JDWP agent (restrictions/security apply
of course).
Back in the JDK 6 time frame (before OpenJDK) we looked into having the
JDWP agent work with a reduced set of JVM TI capabilities (meaning
capabilities that could not be obtained in the live phase). We also
looked into re-generating the interpreter at runtime with the debugger
hooks so that when the debugger agent is loaded it could obtain all the
capabilities that is needed.
It would good to write up some of the options that have been, or could
be, explored. Some of them would likely require significant effort to
implement of course.
My concern with the feature pushed to JDK 12 is that it went into
without sufficient discussion of the alternatives and implications. I'm
also concerned about the usability and ad-hocness. As I see it, I need
to configure my VM to start with the JDWP agent. Some time later I will
use jcmd to trigger the JDWP agent to start its listener and jcmd will
reveal the transport endpoint. I then ask my debugger to connect to that
endpoint. I am of course familiar with the legacy onuncaught/onthrow
options and how they launch the debugger but I don't think there were
well thought through very well at the time.
So I think this feature needs another look to see if it's the right
solution for the JDK. A second look could potentially see if there is a
role for the attach API, at least for the same system case, so that
there is something equivalent to startManagementAgent that would attach
to the VM and trigger the JDWP agent to load its transport and establish
the connection.
-Alan
