This is a follow-up to https://bugs.chromium.org/p/chromium/issues/detail?id=765406.

Summary:

PartitionAlloc has a concept of a PartitionSuperPageExtentEntry. This is a contiguous range of 2MB Super Pages. These Super Pages are subdivided into "PartitionPages" which are then assigned into PartitionBuckets. Allocations are then taken from the PartitionBucket.

For a given PartitionRoot, there is a linked-list of PartitionSuperPageExtentEntry. New entries are added when an attempt to grow the current entry fails, likely due to the range colliding with a section of the virtual address space that was reserved by something else (eg an ASLR mapped module).

The problem is, within a single extent, new super-pages are not coalesced. This causes internal fragmentation of the Virtual Address space in the extent which, in the worst case, could leak up to 47% cases in the pathological case.

While 765406 addressed the commit leak, it did not address the VA fragmentation (which is an effective leak). On 32-bit systems, this may actually be significant.

Fixing this requires two things:
  (1) Relocating the PartitionPage metadata from SuperPage start to Extent start
  (2) Removing the guard pages at the start/end of a SuperPage when coalescing.

The first is required because having the metadata located at the start of a SuperPage will necessarily fragment the extent.  Moving it would require creating a larger metadata region and may have some effects on hot-path cache coherency. This would also create an implicit max size for the whole extent which may have some effects on external fragmentation depending on how we decode to allocate subsequent extents (currently, it just chooses a random page-base which would be the source of external fragmentation).