MLton space pig

[Stephen Weeks]

> Something  is  funny  space-wise  in the 2001-03-21 version of MLton.  If you
> grab the URL
>     http://sourcelight.com/Z/bloat.tgz
> 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
a look.

> 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.