RFR: 8353264: ZGC: Windows heap unreserving is broken

[Stefan Karlsson]

On Wed, 2 Apr 2025 13:28:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Okay.
> 
> Curious, was this a day zero problem?

I think it was. For completeness, this is the unreserve paths you need to hit to hit this bug:

bool XVirtualMemoryManager::reserve_contiguous(uintptr_t start, size_t size) {
  assert(is_aligned(size, XGranuleSize), "Must be granule aligned");

  // Reserve address views
  const uintptr_t marked0 = XAddress::marked0(start);
  const uintptr_t marked1 = XAddress::marked1(start);
  const uintptr_t remapped = XAddress::remapped(start);

  // Reserve address space
  if (!pd_reserve(marked0, size)) {
    return false;
  }

  if (!pd_reserve(marked1, size)) {
    pd_unreserve(marked0, size);
    return false;
  }

  if (!pd_reserve(remapped, size)) {
    pd_unreserve(marked0, size);
    pd_unreserve(marked1, size);
    return false;
  }

  // Register address views with native memory tracker
  nmt_reserve(marked0, size);
  nmt_reserve(marked1, size);
  nmt_reserve(remapped, size);

  // Make the address range free
  _manager.free(start, size);

  return true;
}


> 
> Incidentally, I remember that we had a problem with NUMA on windows where we only released the first NUMA stripe, leaving the other stripes around for future commits to trip over. But ZGC is probably not affected by that, since it does not use os::reserve/release_memory, right?

It doesn't sound like ZGC would be affected by that. At least not via those APIs.

FWIW, I've identified another corner-case bug on Windows that only happens if we end up allocating discontiguous heaps, which only every happens if all our attempts to allocate a contiguous heap fails. I'm in the process of trying to write a test showing this issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/24377#issuecomment-2772671014