[MLton] cygwin and mmap

[Matthew Fluet]

Although we've now gotten most things squared away with x86-cygwin and the 
MLton.Process.* functions, I'm tempted to switch the 
MLton_Platform_CygwinUseMmap default from FALSE to TRUE.

I did a bit of archeology and discovered that the default was TRUE 
in the 20051206 release (established by r4104).  The limitation at the 
time was that a Cygwin-hosted self-compile wasn't possible:
   http://mlton.org/pipermail/mlton/2005-October/028101.html
   http://mlton.org/pipermail/mlton/2005-November/028182.html
Another limitation at the time was that while there was a use-mmap runtime 
option, there was no dont-use-mmap runtime option.  That it, it wasn't 
possible with the 20051206 release to disable the use of mmap.

On the other hand, the default was FALSE in the 20070826 release.  The 
reason for the revert is that the x86_64 branch had been created on 
20050822 and the runtime system was getting a major rewrite.  I was 
cherry-picking commits from trunk and r4104 was one that was never picked 
up.  So the old default got propagated.  Furthermore, at the time of the 
20070826 release, my only Cygwin machine was a 512MB laptop --- not 
suitable for a self-compile.

While there have been a few reported issues with the 20070826 release on 
x86-cygwin (for many of which, use-mmap was the suggested fix), it isn't 
clear that anyone has been self-compiling on x86-cygwin, although there 
have been some experimental packages.

For the present work, I've been running Cygwin/Windows-XP under VMWare 
Server 2.0, which has worked fairly well.  I've been able to perform 
multiple rounds of self-compiles, both with CygwinUseMmap defaulting to 
FALSE and to TRUE.  Furthermore, with CygwinUseMmap defaulting to TRUE, I 
am able to pass *all* the regressions (except textio.2.sml, which is due 
to CR/LF conversions, and socket.sml, which might be due to Windows 
firewall).  Obviously, with CygwinUseMmap defaulting to FALSE, none of the 
regressions that rely on fork() pass.  In any case, I've changed the 
use-mmap runtime option to take a boolean value.

One caveat is that, thus far, the virtual machine has been configured with 
4G memory (although Windows only reports seeing 3G), so the 
garbage-collector and virtual-memory systems are not being stressed 
terribly.  I'll try configuring down to 2G (and maybe down to 1G) and see 
if things remain stable.