RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2]

[Johan Sjölen]

On Tue, 14 Oct 2025 07:05:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this.
> 
> FWIW, in ZGC we deal with similar situations by using this construct instead of a recursive lock:
> 
> ```
> static bool try_lock_on_error(ZLock* lock) {
>   if (VMError::is_error_reported() && VMError::is_error_reported_in_current_thread()) {
>     return lock->try_lock();
>   }
> 
>   lock->lock();
> 
>   return true;
> }
> 
> void ZPageAllocator::print_usage_on(outputStream* st) const {
>   const bool locked = try_lock_on_error(&_lock);
> 
>   if (!locked) {
>     st->print_cr("<Without lock>");
>   }
> 
>   // Print information even though we may not have successfully taken the lock.
>   // This is thread-safe, but may produce inconsistent results.
> 
>   print_total_usage_on(st);
> 
>   StreamIndentor si(st, 1);
>   print_partition_usage_on(st);
> 
>   if (locked) {
>     _lock.unlock();
>   }
> }
> ```
> 
> I don't know the reason for NMT trying to take the look recursively in the error reporter, but maybe something similar to the above would work without adding a new RecursivePlatformMutex?
> 
> Here's another example that simply skips some hs_err logging if the lock is being held (This time with Mutex, though):
> 
> ```
> void GCLogPrecious::print_on_error(outputStream* st) {
>   st->print_cr("GC Precious Log:");
> 
>   if (_lines == nullptr) {
>     st->print_cr("<Not initialized>\n");
>     return;
>   }
> 
>   if (!_lock->try_lock_without_rank_check()) {
>     st->print_cr("<Skipped>\n");
>     return;
>   }
> 
>   if (_lines->size() == 0) {
>     st->print_cr("<Empty>\n");
>   } else {
>     st->print_cr("%s", _lines->base());
>   }
> 
>   _lock->unlock();
> }
> ```

That pattern may work for us, as we do not take the lock often. I'll look into this as an alternative path forward.

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

PR Comment: https://git.openjdk.org/jdk/pull/27759#issuecomment-3407496411