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