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

[Langer, Christoph]

Hi Alan,

> > 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.

I agree that "debugging on demand" is a big topic. I guess it probably merits an own JEP. Since we have (had) some experience with it, in our proprietary SAP JVM derived from the Oracle licensee sources, we were discussing how we could contribute our enhancements to the OpenJDK. We were a bit shy about going the big way involving a JEP because we know that it would certainly involve more than just collecting the single bits and pieces that we have and commit them but we'd probably need to also explore areas where we didn't yet look into yet. The fear was that such a big project is beyond our capacities and hence we decided to try to go the route of trying to bring in small, useful enhancements, such as the onjcmd option for the JDWP agent. But we should probably rethink our strategy here - maybe a JEP will be the right way to go.

> 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.

Ok, we must admit that we missed out the CSR process at the time when we brought the enhancement in for review. So, let's do it now. I would really like if we could get to an agreement about the onjcmd feature where we "improve" it rather than back it out. As we've given the input in the CSR, we've moved it to Finalized. Can you please review it and give us some guidance about what's required next?

> 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.

Ok, that's a thing to look at. However, since I think the JVMTI agent needs to be loaded before the VM is initialized (because of required capabilities), I don't think it's feasible to activate it on a running JVM via an attach API - or at least not without larger modifications.

So, please guide us through the review of this feature.

Thanks
Christoph