ReleaseFreeMemory holds page heap lock for a long time

I'm working on an application which accumulates large heaps (100GB+) and then deallocates nearly the entire heap almost instantly. We call ReleaseFreeMemory() to drop the RSS down to a small value, but found that it can sometimes hold the page heap mutex for 10+ seconds, causing unacceptable latencies, timeouts, etc.

Most likely the slowness comes from the actual madvise() calls, rather than from finding the spans to release. It would be great if there were a way to move these madvise() calls outside of the lock -- for example, by moving the spans to the RETURNED_FREELIST before calling madvise, and madvising after releasing the lock. Of course, things get tricky with memory accounting and ensuring that the spans aren't later re-used, but curious if anyone has prototyped anything like this.

Start at ReleaseFreeMemory and trace the page heap mutex, span selection, and madvise calls. Investigate whether spans can be safely moved to the RETURNED_FREELIST before madvise without breaking memory accounting or allowing reuse. Done means reducing lock-held latency while preserving correct span ownership and RSS release.