jcmd - executing multiple commands at the same safepoint?

[Erik Gahlin]

Not sure if this will have an impact, but we have plans to add 
parameterization to JFR.start.

It will work like the recording wizard in JMC. All the the widgets you 
see in the dialog will be available from command line. For instance, you 
will be able to do something like this (syntax and naming have not been 
decided)

jcmd <pid> JFR.start gc-level=detailed exceptions=true 
method-sampling=10ms classloading=true

The parameters are not fixed at compile time, but instead depends on the 
.jfc file in use. This will simplify usage of JFR as you will no longer 
need to export a .jfc file from JMC if you want to configure events. The 
parameterization will also be available from -XX:StartFlightRecording, 
which uses a comma-separated list.

Furthermore, JFR also supports custom settings, which can have arbitrary 
syntax and semantics. For instance, it will be possible to add a setting 
that will filter out events for a particular thread and have it exposed 
to jcmd as a parameter, i.e.

jcmd <pid> JFR.start threads={Thread1,Thread2, .*Pool.*}

The diagnostic commands for JFR are implemented in Java, so they will 
not be able to execute during a safepoint, so I don't expect there to be 
an issue, but I thought I should mention it.

Erik

> Hi Thomas,
>
> very positive suggestion.
>
> One observation:
> There already seems to be some different interpretation of the command 
> line in different Java versions:
> For instance when I try to dump a flight recording in 1.8.0_152-ea-b05 
> : I can use:
> jcmd 33014 JFR.dump filename="recording1.jfr" recording=1
> but in build 9+181 , the same command must be:
> jcmd 33014 JFR.dump filename="recording1.jfr",recording=1
> (the comma to separate sub-options you mentioned earlier)
>
> Therefore the suggestion without curly brackets, giving several 
> commands after one another seems good with regard to backwards 
> compatibility.
>
> Motivation: hawt.io <http://hawt.io> uses the 
> MBean com.sun.management:type=DiagnosticCommand to access the same 
> functionality as jcmd. Variations in option syntax across Java 
> versions is already an issue (only affecting sub-options though, as 
> each command is a separate JMX operation). So syntax compatibility is 
> highly appreciated :-)
>
> Martin
>
> lør. 12. mai 2018 kl. 20:11 skrev Kirk Pepperdine 
> <kirk.pepperdine at gmail.com <mailto:kirk.pepperdine at gmail.com>>:
>
>
>     > On May 10, 2018, at 11:26 AM, Thomas Stüfe
>     <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>> wrote:
>     >
>     > On Thu, May 10, 2018 at 9:13 AM, Kirk Pepperdine
>     > <kirk.pepperdine at gmail.com <mailto:kirk.pepperdine at gmail.com>>
>     wrote:
>     >> The stacking at the safe point would be a huge win. Right now
>     thread dump consistency can really confuse people as the tooling
>     will show two threads owning the same lock at seemingly the same
>     time. Reality, it’s just that people didn’t realize you get a safe
>     point for each thread therefor there is motion in the system as
>     you’re collecting the data.
>     >
>     > I am a bit confused. What tooling are you talking about?
>
>     jstack. I’ve not seen it with jcmd. But I often see 2 threads
>     holding the same lock at the “same time” which is of course
>     non-sense. I can dig one up for you if you’re still confused.
>
>
>     >
>     >>
>     >> As an aside, it’s amazing how many dev’s aren’t aware of jcmd.
>     Just yesterday after my session at Devoxx I had someone ask me
>     about using jfr from the command line, many in that session had
>     not seen jcmd before. The feedback was, wow, this is very useful
>     and I wished I had of known about it earlier.
>     >
>     > Yes, jcmd is quite useful. I also really like the simple design,
>     which
>     > is by default up- and downward compatible (so you can talk to
>     any VM,
>     > new, old, it should not matter). That is just good design. We -
>     Sap -
>     > work to extend jcmd, to help our support folks. E.g. the whole new
>     > VM.metaspace command chain.
>
>     And simple it is….well done!!!
>
>     — Kirk
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180522/9cf8d8d9/attachment.html>