On Tue, 5 May 2026 15:00:01 GMT, Johan Sjölen <[email protected]> wrote:
> Some general comments. I can see that we do these Thread::is_revived checks > in some places, and then do something special. How are we supposed to > understand when we're meant to insert these into the code or why they are > inserted at those particular places :-)? Good question 8-) When a core dump is revived, we are not running any regular JVM activity like GC or Compiler threads, just the diagnostic command. So most JVM features don't need to worry. The special cases should be rare, and only in places that might be called from a diagnostic command, but which might make assumptions that revival could break. e.g. assumptions about threads might be available when heap dumping - VM_GC_HeapInspection should not look for GC helper threads (an extreme slow path example). There are diagnostic commands that might show file system information, like the dynlibs list, which is not enabled for dumps as it might be misleading. Any new diagnostic command that reports something from the OS or file system might be one that we don't enable for core dumps. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31011#issuecomment-4390559766
