On Tue, May 28, 2019 at 12:19 AM David Holmes <[email protected]> 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 > > >
