On Fri, 8 May 2026 06:12:44 GMT, David Holmes <[email protected]> wrote:

> I've taken an initial walk through the VM changes...

Thanks David - 

CRaC is an interesting parallel, which cares about a lot more than we revive 
here, e.g. file descriptors etc, and gets you in a state to really continue 
running.  But it is Linux specific.  This is a less complete revival for 
diagnostic purposes only, and is not integrated with the OS (does not require 
support from the OS), and it runs on a regular core or minidump, not another 
format.

You have summarised this correctly.  Being a VMThread is only needed because 
some DCmds might use a VMOp, and we don't want our thread to go requesting the 
(non-existent) original VMThread to run it.  The stack memory of threads is 
revived from the core file, so is available for inspection.  But there are no 
other threads as far as the OS is concerned.

Comments also in response to your comment about the Mutex code, I like the 
rename.  

The VM checks for revival hope to be quite minimal.  Code that could run from a 
diagnostic command, and makes assumptions about threads or other state that 
might no longer be true, may need the is_revived() special case.

Anything self-contained in the VM should be fine.  These checks could increase 
if there are diagnostic commands that query the live system, which we also 
enable for core dumps.  Diagnostic commands have to be specifically enabled for 
revival when added, so new commands should opt-out if any doubt.

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

PR Comment: https://git.openjdk.org/jdk/pull/31011#issuecomment-4405633632

Reply via email to