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

[Yi Yang]

On Tue, 2 Nov 2021 06:01:02 GMT, Thomas Stuefe <stuefe 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.

I agree that this is a matter of taste. I prefer the minimalist command list, but I don't have a strong desire to make such changes, just a rough idea. The current jcmd commands are somewhat arbitrary, we are able to normalize it in some way in the future.

Going back to our topic, I think if possible, using the new command VM.classes instead of adding decorators to VM.class_hierarchy might be a better choice.

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

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