On Wed, 31 Jan 2024 14:22:44 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. (I started a CSR but have withdraw it, as it is established that jcmd is a diagnostic tool, and does not require a CSR for new options, similar to HotSpot diagnostic flags). Adding jcmd access to debug tools, for a live process. That includes a process started with -XX:+ShowMessageBoxOnError which has stopped with an error. At that point, the VM has not created the hs_err fatal error log, but we can already run "jcmd PID VM.info", to provide much of what would appear in the hs_err log, and a native debugger can be attached to discover the call stack. The "find" subcommand reads an address from the text of its parameter, to lookup pointers found in VM.info output or in gdb sessions. It is protected by the UnlockDiagnosticVMOptions option (so is always enabled in debug builds). With the dbg_is_good_oop changes here, I can examine hundreds of pointers around a known good oop, recognise bad objects as such and skip them, without crashing. Before the additions, it was possible to crash the target, e.g. following a null klass pointer when looking at an address that is not an object. The "not recommended for live production use" advice still stands, and diagnostic option requirements remain, in case a crash is possible when the find command is given a pointer to the right (or wrong) kind of data in the Java heap. Aimed at people with source code access/familiarity, hence not documenting the findclass/findmethod flags in great detail. Commands and output should be expected to evolve. Thanks @LudwikJaniuk for the nits above, and for the other testing you did with this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1921013935 PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1923692015
