The reasoning behind this change is explained in D33454, which unfortunately
broke the Windows version (due to the platform not supporting partial unmapping
of a memory region).
This new approach changes MmapAlignedOrDie to allow for the specification of
a padding_chunk. If non-null, and the initial allocation is aligned, this
padding chunk will hold the address of the extra memory (of alignment bytes).
This allows AllocateRegion to get 2 regions if the memory is aligned
properly, and thus help reduce fragmentation (and saves on unmapping
operations). As with the initial D33454, we use a stash in the 32-bit Primary
to hold those extra regions and return them on the fast-path.
The Windows version of MmapAlignedOrDie will always return a 0
padding_chunk if one was requested.
How about this:
Since the predominant use case of this function is "size == alignment" and the nature of the
way the alignment requirement is satisfied (by allocating size+alignment bytes of memory), there's a potential
of address space fragmentation. The padding_chunk parameter provides the opportunity
to return the contiguous padding of "size" bytes of the allocated chunk if the initial allocation happened to be
// perfectly aligned and the platform supports partial unmapping of the mapped region.