[MLton-user] Slow GCC

[Stephen Weeks]

> > More information: if I do a mlton -stop g and then a mlton on the .c
> > and .S files, it takes no time at all to do the gcc part, but if I run
> > the whole thing as one big mlton job, gcc swaps like mad.
...
> That sounds like it could be a potential space leak.  mlton does a full 
> gc before invoking (fork/exec-ing) gcc, so there really shouldn't be 
> more live heap data in the normal run than in the -stop g/mlton *.c *.S run.

I suspect it's a Windows-specific virtual memory issue.  Neal could
check this by doing the compile on another platform, say, Linux and
verify that virtual memory usage drops when gcc is called.

On Cygwin, by default MLton uses Virtual{Alloc,Free} to handle virtual
memory.  MLton packs the heap using MLton.GC.pack before calling gcc.
This shrinks the heap and calls VirtualFree (..., MEM_DECOMMIT) on the
newly available memory.  I'm not positive, but given the observed
behavior, perhaps MEM_DECOMMIT isn't making the space available to
other processes?  I can't remember offhand why pack doesn't use
MEM_RELEASE, but it doesn't.


Another thing to try would be to use the use-mmap runtime option, as
in:

  mlton @MLton use-mmap -- foo.sml

On Cygwin (and Cygwin only), this tells MLton (or whatever
MLton-generated executable) to use Cygwin's mmap emulation.  This has
other problems, but it's worth a try.


As to generating smaller files, you can compile with -coalesce, as in:

  mlton -coalesce 2048 foo.sml

The default is 4096, and the scale is linear.  This flag affects the
size of the generated C and asm files.  Although it doesn't always
help -- the outliers are sometimes not any smaller.