[MLton] Address space in windows
fluet at tti-c.org
Mon Oct 13 14:18:33 PDT 2008
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
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
> 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
One could even attempt this mremap emulation on *BSD/darwin, where no
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
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).
More information about the MLton