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 <[email protected]
<mailto:[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
>