On Tue, 5 Mar 2024 11:31:13 GMT, Kevin Walls <kev...@openjdk.org> wrote:
>> Introduce the jcmd "VM.debug" to implement access to a useful set of the >> established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...". >> >> Not recommended for live production use. Calling these "debug" utilities, >> and not including them in the jcmd help output, is to remind us they are not >> general customer-facing tools. > > Kevin Walls has updated the pull request incrementally with one additional > commit since the last revision: > > Test update Hi, > once you start poking at the JVM innards at this level, I guess you will be > quickly at the limit of what this command can do for you and need to attach a > debugger anyway. I think we all expect a collection of features in the toolbox. This jcmd will not remove the need for a native debugger. I do think that the JVM should be in charge of decoding its own internals, and the built-in tools that do that should be more accessible. > Could this be an own command, e,g, VM.inspect, and possibly limited to debug > VMs? Yes, could be VM.find or VM.inspect. I liked the grouping into VM.debug, they have some common features: a conceptual group, tools that you might want to call alongside another debugger origins in debug.cpp utils (which are still there) "debug" label may discourage casual users from experimenting require UnlockDiagnosticVMOptions common ..but I'm not emotionally connected to the name or the group. I appreciate the feedback. As noted, there is no rule for jcmd grouping. VM.info yes is an example that doesn't fit one particular category, find/inspect is certainly another. (If you find existing jcmds a mess, feel free to suggest changes as appropriate.) > Do we really need this feature in production? Yes I am saying this should be in all builds. It's not only debug builds that people debug, or reproduce problems with. > Don't we have jhsdb for that? [core file/minidump handling] We have jhsdb and the SA tools in general. These have ongoing maintenance issues, the game of catch up as the VM changes is not solved. We need to have options. I will find a different place to propose that alternative in detail. I'll wait and see if there's any other input on the naming... 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1980761622
