On Mon, 4 Mar 2024 15:10:12 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 three additional > commits since the last revision: > > - Usage correction > - Help to clarify this is VM inspection. Comment to relate source to > debug.cpp. > - jcheck trailing whitespace Hi Thomas @tstuefe - Security concerns certainly needed some thought. We have remote access to DiagnosticCommands over JMX. I don't see a particular need for that for this command. I think it was keeping the DCmd flagged as hidden that hides it from the list of dcmds available in that way. So we have the attach api controls using local user identity, as we do for everything else. Yes, "events" is not that useful, I should remove it. I was taking the useful parts of debug.cpp, and although the events were in VM.info, I had missed that since your JDK-8224600, VM.events is its own command now! Thread.print with stacks, vs "VM.debug threads" which is just a thread list, so you have e.g. JavaThread*, name, native id, stack range. "find": Usage at the moment, would likely be MessageBoxOnError, and a native debugger to get the native stacktrace and parameters that include an object reference you care about. It might be other jcmds if e.g. events capture a relevant problematic pointer, but likely it involves a native debugger. Using jcmd behaves better, showing the output where you run jcmd, not in the VM's current output as the debug.cpp utils do. Native debugger syntax to call abritrary functions can be awkward, particularly on Windows, so the jcmd should be a better experience. This might be more compelling in post-mortem usage. Am working on that. i.e. jcmd on a core file. But I am saying it offers some value today. The class/method finders, I've heard some enthusiasm for their inclusion. We don't want to encourage overlap but yes we do have some overlapping jcmds. This is an umbrella but I don't think it's vague. VMDebugDcmd is for inspecting VM state. It's inspired by debug.cpp utilities, does not need to implement all of them, but does aim to make them more accessible (I will assert that they are not well known, which is hard to prove.) Do we have a problem with jcmd feature creep? If anything has crept too far it can be addressed. Looks like the DCmd classes have approximately doubled since jdk8u but this looks like growth in a good way. Thanks Kevin ------------- PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1977543469
