RFR: 8275775: VM.metaspace prints flag 'f' for classes that have non-trivial finalize() [v3]

[Thomas Stuefe]

On Tue, 2 Nov 2021 03:40:37 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Personally and ideally, I hope JCMD can provide several types of general commands, allow users to quickly find what they want, and then we can add more subcommands for advanced usages.
> 
> For example, we provide:
> 
> ```
> VM.classes
> VM.classloaders
> VM.stringtable
> VM.symboltable
> VM.cds
> VM.metaspace
> ```
> 
> It’s easy to know what it does and what users want. Then we add some subcommands for debugging/diagnostic support. In this way, we can further simplify the current commands, such as:
> 
> 1. VM.classloaders = VM.classloaders + VM.classloader_stats
> 
> VM.classloaders prints current class loaders(VM.classloader_stats), we can also provide some advanced argument such as "hierarchy"(actually what VM.classloaders does now), "details" to print more information.

Both commands do different things. VM.classloaders prints out a tree-like structure, not a table. I added VM.classloaders 
because we needed a quick way at SAP to display our sometimes insanely complex loader hierarchy. Printing that tree-like structure requires a different logic for printing a simple table, since it is not stateless (see classLoaderHierarchyDCmd.cpp). 
Code-wise I doubt you save a lot complexity by combining those commands. As for simplifying user-facing commands, it is a matter of taste, see below (but note that changing existing commands introduces backward compatibility issues).

> 
> 1. VM.command_line += VM.flags
> 
> VM Arguments: jvm_args: -agentlib:jdwp=transport=dt_socket,address=localhost:23158 jvm_flag: <<<<>>> java_command: jdk.jshell.execution.RemoteExecutionControl 33170 java_class_path (initial):. Launcher Type: SUN_STANDARD
> 
> Roughly thoughts.

Do you want tiny minimalist commands doing one thing and that well? Or do you want a meta-command for one area and hide all the functionality in sub options? It is a matter of taste, mostly.

There are some advantages to the minimalist approach. E.g. you can just query the hotspot for capabilities by getting a list of commands. That makes outside scripting wrt different hotspot versions easier. But with a meta-command, you don't have that.

We have similar decisions in other areas too, e.g. command line switches. Most hotspot command line switches are atomar. They describe one thing. But there are meta-switches, e.g. -Xlog or -XX:StartFlightRecording. There, a bunch of sub options was packed under one flag, requiring extra parsing code for these and, for me, are always more difficult since they follow an own logic (e.g. I always have to look up Xlog syntax).

I'm not saying jcmd is perfect. To me, jcmd feels like a framework where we never really agreed on one syntax, and as a result the commands feel a bit arbitrary. E.g. we have meta commands (VM.metaspace) and atomar commands. But instead of combining commands, maybe one could introduce command groups. E.g 
`VM.classloaders.stats`. `VM.classloaders.tree`. Etc. 

Even only a visual separation when printing the command list would help already. E.g. combining all classloader-related commands under one header. Though deciding what goes where may be difficult, e.g. for VM.metaspace.

 Just a thought.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6075