[MLton] Address space in windows

[Matthew Fluet]

On Mon, 13 Oct 2008, Wesley W. Terpstra wrote:
> I wrote a quick program (attached) to see how big the memory
> chunks available are.

Missing... (though, not necessarily important).

> I propose the following three changes:
> 1. Eliminate the use of VirtualAlloc/Free on cygwin. mmap can acquire
> just as much memory and presumably cygwin tracks mmap for use in
> fork().

At one point, there were issues with Cygwin's implementation of mmap, 
which motivated the inclusion of VirtualAlloc/Free.  On the other hand, 
looking at the commit logs, it appears that one does need to use mmap to 
use Cygwin's fork().

> 3. Implement our own portable mremap.
>
> According to SUSv2: "The function munmap() removes any mappings for
> those entire pages containing any part of the address space of the
> process starting at addr and continuing for len bytes."

I guess you are arguing that SUSv2 munmap() suffices to batch free any 
(contiguous) set of mmap-s; thus, one doesn't need to change the Cygwin 
implementation.

> ie: If we map pages directly before or after an existing mmap(), one
> munmap will release both mappings. To grow the map, try adding the new
> space with a mapping at the end of the existing map. If it fails,
> binary search to find the maximum expansion we can achieve. Then try
> to grow the map at the front of the existing map for the remaining
> required space. If this succeeds, memmove the buffer.

I'm guessing here, but I would suspect that a potential downside of this 
over a 'native' mmap is that we could end up with a large number of 
mmap-s, as a heap is grown in place little by little.  It also misses the 
opportunity to move the region whole-sale to a completely different 
address (more likely to be a possibility in a 64-bit environment). 
Nonetheless, I agree that this would appear to give the right mremap 
semantics.

One could even attempt this mremap emulation on *BSD/darwin, where no 
mremap exists.

One needs to be careful to use MAP_FIXED in order to get the new mappings 
in exactly the right places.

> I imagine doing this by modifying the remapHeap implementation in
> gc/heap.c. I'm testing out this idea now, but have no results yet.

Why modify remapHeap in gc/heap.c?  You should do the changes in 
platform/*, adding/modifying the implementation of the the GC_mremap 
function.


One could also perform a related experiment, where one uses 
'malloc/realloc/free' in place of 'mmap/mremap/munmap'.  The former are 
all required by POSIX (whereas mremap is only available natively on 
linux).  One issue is that realloc (according to the spec) could move the 
allocation, even if the reallocation is shrinking the allocation.  There 
are situations (e.g., shrinkHeap), where we want to release the unused 
portion of the heap, without moving the heap (because moving the heap 
requires translating all the heap pointers).