RFR (M) 8223456: CSR Delayed starting of debugging via jcmd

[Alan Bateman]

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