MLton space pig
Mon, 28 May 2001 13:51:02 -0700
> Something is funny space-wise in the 2001-03-21 version of MLton. If you
> grab the URL
> you will see a SML program. The whole thing is only 483 lines worth of SML
> code, nothing fancy, no functors, and yet it requires 512 meg of RAM to
> compile. I ran it with -v3 and turning on gc-messages. The max live is just
> under 150 megabytes. Other than all the gc messages, and the various listing
> of /tmp files, the message just before the blowup is
> outputAssembly starting
> and the message just after is
> translateChunk totals 0.03 + 0.0 (0.0% GC)
I observed the same problem as you. The outputAssembly message means that the
X86 code generator is starting. Since the amount of time it takes (on my
machine) to reach that point is about two seconds and the amount of space is not
that much, I bet there is a problem in the X86 codegen. There haven't been any
changes to the codegen since 2001-03-21, so the bug has probably been around for
a while. Matthew is starting here tomorrow (Tuesday), so hopefully he can take
> The compile also took 73 CPU seconds, which seems a bit much given how much
> smaller it is than the self compile, but I'm not really concerned by that.
> My concern is this real blow-up in space used, which means even for
> relatively small programs you need a rather large machine. To be specific, I
> can't compile this program on my laptop (which only has 128K), which is both
> surprising and a pain.
> Just in case, I tried doing the compile with -no-polyvariance. This had no
> effect on either max bytes live or CPU time.
Yeah, both the intermediate CPS size (from -keep cps) and the final executable
size are small, so the problem is likely data structure bloat in the codegen.
For now, you can compile with -native false, which only takes 6 seconds and uses
42M on my machine.
We'll let you know more tomorrow, I hope.