MLton RAM usage

[Stephen Weeks]

> Ahh! This also explains why I can now compile with only 512 MB
> without setting the "max-heap m450" flag. Because I first compiled
> and installed the compiler with this flag set, and now
> I'm compiling again without the flag, but it's using the
> world.mlton from the previous compile.

Makes sense.

> Maybe this will also explain why I recently saw one of my own
> apps running out of memory after a while, even though it
> shouldn't be using that much mem. I really just thought
> that I had a non-tail recursive main-loop or something! :)
> I was using my patched version of MLton 1999-7-12 when it
> happened, so this is probably a really old bug.

I agree with Henry that this is an unrelated bug, and could either be a compiler
bug or a bug in your application.  We need more data to decide.

> Well, I guess the compiler saves the basis library as world.mlton, and I
> might have had the swap space enabled when compiling the compiler - and
> it was not when running the app.

Swap space doesn't matter.  All that matters is total RAM. 

> But I'm also thinking of another thing - does getRAMsize look at
> how much memory is available or at how much is free? In my opinion
> it should look at free memory and not available...

No, MLton does not look at free, it just looks at total RAM.  We wanted to pick
a default that would let us run apps (including the compiler) as successfully
and quickly as possible.  And since our runtime is such a space hog, we decided
to go for the larger amount.  The max-heap and fixed-heap stuff is for more
sophisticated users who need to limit space.  I agree it's not ideal.  Does
anyone know if there's an easy way to get the amount of free RAM?  

The main annoyance for us to add this is complexity in compiler switches to
specify the approach you would want (unless we can all agree on one) and
communicating it to the runtime.  Anyways, if this becomes a serious problem for
you, let us know, and we can add the switch.