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

[Thomas Stüfe]

On Tue, May 28, 2019 at 12:19 AM David Holmes <david.holmes at oracle.com>
wrote:

> On 28/05/2019 12:33 am, Langer, Christoph wrote:
> > Hi Alan,
> >
> >> On 27/05/2019 14:23, Schmelter, Ralf wrote:
> >>
> >> I need reviews for the following CSR:
> >> https://bugs.openjdk.java.net/browse/JDK-8223456
> >> Note that this CSR is for a feature which already was commited to JDK
> 12.
> >>
> >> I think this feature needs to be re-examined, maybe backed out or the
> >> onjcmd sub-option hidden from the help output if we can't get agreement
> >> before JDK 13 RDP1. It's unfortunate that it was pushed to JDK 12
> without a
> >> CSR because that would have been the opportunity to ask questions. The
> >> problem with this feature is that it ties the debugger agent to a
> unrelated
> >> JDK-specific tool. It feels like it conflates two things.  So I think
> the "feature"
> >> needs to be re-discussed to see whether the scenario is really
> compelling
> >> and to see the list of alternatives that were explored.
> >
> > I don't fully understand what you are saying, especially the part "it
> ties the debugger agent to a unrelated JDK-specific tool".
> >
> > 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.
> >
> > Anyway, I have reviewed Ralf's CSR and we've put it to status
> "Proposed". We're open for discussion, of course, on how to optimally
> implement this in OpenJDK. E.g. I personally don't think the naming of the
> option "onjcmd" is a good choice. And there's probably more around this
> feature which we'd need such as means to get the listen address of the
> debugger (or to get the JDWP agent's configuration, reconfigure it or
> disarm it). Maybe this can all be part of the CSR (or an upcoming CSR).
> Maybe it's even a candidate for a JEP, I don't know. So let's use the CSR
> to discuss this.
> >
> > By the way, I had asked at the time the change was reviewed, whether we
> needed a CSR [0] but didn't get a response. Sometimes it's not easy to get
> people involved and a fruitful discussion started, like the one you are
> obviously wishing for...
>
> I find it frustrating, from a CSR Group member perspective, that people
> too often need someone else to tell them a CSR is, or is not, needed
> rather than being able to evaluate that for themselves. Thinking about
> the need for a CSR request should be on everyone's "checklist" before
> proposing any new feature or significant change. And yes it should also
> be part of the reviewer's review criteria.
>
> That said the only guaranteed additional exposure a CSR provides is to
> the CSR Group lead - Joe - who will do the actual approval. Even CSR
> Group members don't get notified of new CSRs - they are just JBS issues
> and you have to watch the right component/subcomponent to get
> notifications. So there is no guarantee that a CSR would have provoked
> any detailed discussion at the time - unless Joe flagged it for some
> reason.
>
> David
> -----
>
>
Yes, the CSR process is important and needs to be carried by all. Doesn't
work any other way.

Joe did a good presentation at the last committers workshop in Brussels,
maybe he could share the slides (again).

Cheers, Thomas


> > Best regards
> > Christoph
> >
> > [0]
> https://mail.openjdk.java.net/pipermail/serviceability-dev/2018-December/026360.html
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190528/d6faf161/attachment.html>