On Thu, May 10, 2018 at 9:13 AM, Kirk Pepperdine <[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? Thread dumps (as in jcmd Thread.info or kill -3) prints thread stacks and does deadlock detection, both in its separate safepoints. So I can see how information between thread stack dumps and thread deadlock detection dumps could be inconsistent, but not in-between threads. > > 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. ..Thomas > > — Kirk > >> On May 10, 2018, at 7:50 AM, Thomas Stüfe <[email protected]> wrote: >> >> Hi Kirk, >> >> On Thu, May 10, 2018 at 8:07 AM, Kirk Pepperdine >> <[email protected]> wrote: >>> >>>> On May 10, 2018, at 7:04 AM, Thomas Stüfe <[email protected]> wrote: >>>> >>>> Oh... maybe. You are right. And I see commas are not good either since >>>> they are used in sub options (e.g. GC.class_stats). >>>> >>>> Alternative ideas could be using brackets surrounding the >>>> command-and-options (e.g. '{''}'): >>>> >>>> jcmd { GC.class_stats columns=InstBytes,KlassBytes } { VM.metaspace >>>> show-loaders } >>> >>> are exposed braces safe in shells? >>>> >>>> I think technically we would not even need delimiters, since the >>>> commands are as keywords limiting enough. E.g. one could just specify: >>>> >>>> jcmd GC.class_stats columns=InstBytes,KlassBytes VM.metaspace show-loaders >>> >>> I’d vote for this form. Simple.. >> >> I think so too. >> >> Note how it would influence the form of jcmd command files: >> >> <command 1> >> <command 2> >> would execute two commands sequentially at different safepoints >> >> <command 1> <command 2> >> would execute two commands at the same safepoint >> >> Arguably though, if we can stack commands at the command line, the >> jcmd file gets less important. >> >> I'll play around a bit and wait what others say. >> >> Thanks, Thomas >> >>> >>> — Kirk >>> >>>> >>>> and that would be for jcmd too. It is more for the benefit of the user. >>>> >>>> On Thu, May 10, 2018 at 7:54 AM, Kirk Pepperdine >>>> <[email protected]> wrote: >>>>> Awesome idea! Would the semicolon would be an issue for shell scripts? >>>>>> On May 10, 2018, at 6:52 AM, Thomas Stüfe <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> just asking around for opinions. >>>>>> >>>>>> I am playing with the idea of bundling diagnostic commands to have >>>>>> them executed at the same safepoint, in order to get results >>>>>> consistent with each other. E.g. a heapdump and a corresponding >>>>>> metaspace statistic. >>>>>> >>>>>> Syntax wise, I think one could specify multiple commands in jcmd >>>>>> separated by comma or semicola: >>>>>> >>>>>> jcmd <command> <option> <option>; <command 2> <option> <option> >>>>>> >>>>>> What do you think, would that be a useful addition? >>>>>> >>>>>> Thanks, Thomas >>>>> >>> >
