Hi Erik, On Tue, May 22, 2018 at 11:08 PM, Erik Gahlin <erik.gah...@oracle.com> wrote: > 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.
Yes, it is good to know that. There are two different problems here: 1) how to specify multiple jcmd commands in a convenient way on the command line 2) how to run them in a single safepoint. For (1) it turns out it already works, in a fashion: We can specify multiple commands when they are separated by newlines. I think that is an unintended side effect of the command file support (-f), but surprisingly also works on the command line if you surround all arguments with a single quote: thomas@mainframe /shared/projects/openjdk/jdk-jdk/output-fastdebug $ ./images/jdk/bin/jcmd test3 'VM.version VM.metaspace basic VM.uptime' which is of course completely unix-unlike and inconvenient to use. It just works because jcmd runner appends all program arguments to a single string, which it sends over to the VM. -- My proposal would be that we change that in a backward-compatible way by specifying that - multiple commands are allowed without having to be separated by newlines. Any whitespace should be a separator: <command>[ <parameter> <parameter>] <command>[ <parameter> <parameter>] - a command name indicates start of a new command. Any token which is not a command name is a parameter for the preceeding command. This should work for JFR too, if your parameters do not contain whitespace-enclosed strings which equal valid command names: JFR.start threads={Thread1,Thread2, .*Pool.*, VM.info} would be invalid since "VM.info" is a valid command name. If that proposal does not work, an explicit notation may be needed, e.g. the initially mentioned enclosing-by-brackets: jcmd { VM.version, VM.metaspace basic, VM.uptime} ---- 2) Yes, there are commands which cannot be run at a safepoint. I would make that a property of the DiagnosticCmd object, and just forbid to stack them with other commands. This is all still very much in the thinking phase. The more I think about this the clearer it gets that implementing it is the smallest part - more time consuming will be to file a CSR and agree on a syntax which is both backward compatible and practical on the unix command line. Best Regards, Thommas > > 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 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.pepperd...@gmail.com>: >> >> >> > On May 10, 2018, at 11:26 AM, Thomas Stüfe <thomas.stu...@gmail.com> >> > wrote: >> > >> > On Thu, May 10, 2018 at 9:13 AM, Kirk Pepperdine >> > <kirk.pepperd...@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 >> >