[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    RE: RFR (M) 8223456: CSR Delayed starting of debugging via jcmd
From:       "Langer, Christoph" <christoph.langer () sap ! com>
Date:       2019-05-31 16:01:37
Message-ID: DB7PR02MB5193AB6BD5250989B4776DEB8A190 () DB7PR02MB5193 ! eurprd02 ! prod ! outlook ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]