Hi Thomas - Yes, it goes into all builds, and yes this is a new jcmd with sub-commands, you could call it a group. It's not a large group of commands, and the commands themselves are not exactly new (but no objection to a CSR).
Getting these debug utilities into a jcmd is about making them more discoverable and accessible (discoverability with bounds, still aimed at a narrow set of technical users), and also more testable. This does not compete with or replace existing debuggers if that's anybody's chosen route. I envisage just adding to the toolkit we have available. Live or at the time of a fault (e.g. MessageBoxOnError) we can inspect JVM state using existing jcmds. Now we can also inspect arbitrary Java heap objects, and items in other VM locations. This may be in parallel with a debugger. You can't run these while the JVM is stopped in another debugger 8-) but you may well attach something temporarily and see references that the JVM itself is well-placed to decode. Where VM.info or Thread.print give you Java object references, "VM.debug find" lets you inspect them, and continue following references with additional invocations. > many folks are at fosdem right now. I hope they have a great time. 8-) Thanks Kevin From: Thomas Stüfe <thomas.stu...@gmail.com> Sent: 02 February 2024 21:42 To: Kevin Walls <kev...@openjdk.org> Cc: hotspot-runtime-...@openjdk.org; serviceability-dev@openjdk.org Subject: Re: RFR: 8318026: jcmd should provide access to low-level JVM debug information Hi Kevin, Having a clear command spec to read and argue about would be helpful, especially since this is not a simple commnd but a whole command group. Exposing such a low level interface (this is supposed to go into product VMs, right?) may carry some risks that could arguably fall unter CSR. That said, what use case do you envisage? To me, these commands are usually only useful in the debugger, when I deal with numerical adresses. Cheers, Thomas p.s. please note that many folks are at fosdem right now. On Fri 2. Feb 2024 at 19:35, Kevin Walls <kev...@openjdk.org<mailto: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. ------------- Commit messages: - Tidy up the safety checks - Whitebox not required, just check option properties. - unnecessary parameter to find - Test update. Recognise ZGC oops differently. Formatting. - typo - Separate is_good_oop... method to avoid changing existing asserts. - More oop safety - 8318026: jcmd should provide access to low-level JVM debug information Changes: https://git.openjdk.org/jdk/pull/17655/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318026 Stats: 371 lines in 5 files changed: 369 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17655/head:pull/17655 PR: https://git.openjdk.org/jdk/pull/17655
