RFR: 8372380: Make hs_err reporting more robust for unattached threads [v3]

[Aleksey Shipilev]

On Mon, 24 Nov 2025 02:34:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> There were a number of places where the code called by hs_err reporting assumed/required an attached current thread. These would then cause secondary failures during hs_err reporting. Using a simple example of an unattached thread causing a SEGV I went through and eliminated all the problems I encountered. In some cases the thread dependency was obvious and easy to address directly, but in others we just skip that section at the top-level.
>> 
>> Testing:
>>  - manual inspection of hs_err file, for different GCs
>>  - tiers 1-3 sanity
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix include order

Looks reasonable, but I have questions:

src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 1013:

> 1011:     st->cr();
> 1012:   }
> 1013:   if (Thread::current_or_null_safe() != nullptr) {

Looks like `check_before_reporting()` does some pre-checks, maybe move it here, and print a helpful message about detached threads?

src/hotspot/share/utilities/vmError.cpp line 667:

> 665:   if (MemTracker::enabled() &&
> 666:       NmtVirtualMemory_lock != nullptr &&
> 667:       _thread != nullptr &&

I do wonder if we want to do the change downstream to cover all these cases?


bool Mutex::owned_by_self() const {
-  return owner() == Thread::current();
+  return owner() == Thread::current_or_null_safe();
}

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

PR Review: https://git.openjdk.org/jdk/pull/28470#pullrequestreview-3499014592
PR Review Comment: https://git.openjdk.org/jdk/pull/28470#discussion_r2555196065
PR Review Comment: https://git.openjdk.org/jdk/pull/28470#discussion_r2555217153