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

[David Holmes]

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

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

Sorry that was interpreting a broader use of `current_or_null_safe`. Just using it here would require:

Thread* current = Thread::current_or_null_safe();
return current != nullptr && owner() == current;

But I don't think this would generally be that helpful - the code doing the check needs to be null-aware. The current code gives us the assertion failure that tells us we have been called by an unattached thread. We can then adjust the calling code to address that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28470#discussion_r2557807994