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