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

[David Holmes]

On Mon, 24 Nov 2025 08:52:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

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

Thanks for taking a look @shipilev !

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

I thought it better to print the initial message even if we can't then print any details.

> 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();
> }

Not really. The "safe" version is only needed if it can be called from a signal handling context. If we changed all of them then we effectively disable language/compiler based use of ThreadLocal!

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

PR Comment: https://git.openjdk.org/jdk/pull/28470#issuecomment-3572833444
PR Review Comment: https://git.openjdk.org/jdk/pull/28470#discussion_r2557794562
PR Review Comment: https://git.openjdk.org/jdk/pull/28470#discussion_r2557797435