RFR: 8369622: GlobalChunkPoolMutex needs to be recursive

[Stefan Karlsson]

On Sun, 12 Oct 2025 12:55:53 GMT, Johan Sjölen <jsjolen 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();
}

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

PR Review: https://git.openjdk.org/jdk/pull/27759#pullrequestreview-3334177089