[MLton-user] Slow GCC
fluet at tti-c.org
Sun Jan 14 09:49:51 PST 2007
>>> 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.
Neal mentioned that, from what he can see, after spawning gcc, both the
original mlton process and the gcc process are holding onto
approximately 400M of memory. It seems like the virtual memory isn't
given up by the forked process when it execs gcc (which I think is the
semantics of mmap under Posix). Even if the memory is copy-on-write,
its taking a chunk out of the virtual memory that gcc sees.
More information about the MLton-user