RFR (M) 8223456: CSR Delayed starting of debugging via jcmd
Joe Darcy
joe.darcy at oracle.com
Tue May 28 17:02:52 UTC 2019
Hello,
For more information about CSR, see the wiki page:
https://wiki.openjdk.java.net/display/csr
and the slides from the February 2019 OCW in Brussels:
http://cr.openjdk.java.net/~darcy/Presentations/OCW/ocw-CSR-2019-02.pdf
The backup slides from the presentation include some information on the
logistics of creating and managing a CSR.
HTH,
-Joe
On 5/28/2019 1:05 AM, Thomas Stüfe wrote:
>
>
> On Tue, May 28, 2019 at 12:19 AM David Holmes <david.holmes at oracle.com
> <mailto: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/b0181beb/attachment-0001.html>
More information about the serviceability-dev
mailing list