RFR: 8318026: jcmd should provide access to low-level JVM debug information [v4]

[Thomas Stuefe]

On Mon, 4 Mar 2024 22:02:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> 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

Hi Kevin, @kevinjwalls ,

thank you for your explanations. Please find answers inline.

> 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.

I remain sceptic here, because in my experience, 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.

Could this be an own command, e,g, `VM.inspect`, and possibly limited to debug VMs? Do we really need this feature in production?

> 
> 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.

Don't we have jhsdb for that?

> 
> 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.

Yeah, I can see this being useful.

> 
> 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.
> 

Normally, we have either single-use commands or commands grouped roughly by the area they belong to. VM.metaspace is a command for various metaspace-related diagnostics. There is no clear policy guarding the form of jcmds, so its already a bit of a mess. E.g. VM.info would be a cross-topic outlier, albeit a very useful one.

VM.debug would introduce a command orthogonal to the usual grouping-by-topic. Is VM.debug, in its class-showing capacity, more "debug" than the class-related commands, including VM.metaspace, we already have? Adding new class-illuminating features should happen now here, instead of adding a new VM.class_xxx command? 

Thanks, Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1978836319