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
<[email protected] <mailto:[email protected]>>:
> On May 10, 2018, at 11:26 AM, Thomas Stüfe
<[email protected] <mailto:[email protected]>> wrote:
>
> On Thu, May 10, 2018 at 9:13 AM, Kirk Pepperdine
> <[email protected] <mailto:[email protected]>>
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
