[MLton] Memory problems with latest CVS?

[Stephen Weeks]

> I'm pretty certain that the bytes is off -- 16 bytes accounts for
> the counter, size, header, and sign words, and doesn't leave any
> room for the actual bignum; certainly not enough for the product of
> those two numbers.

Excellent work!

> basis/integer/int-inf.sml
> Revision 1.18
> Tue Jan 6 05:12:26 2004 UTC (8 months ago) by sweeks
>
> the size of a small bignum changed from 1 to 0.  So, at one point we were
> calculating that the reserve size should have been 24 bytes (the 16 bytes
> of header + 4 * (1 + 1)).

Yes this is the problem.  It looks like I made the change to make
MLton.IntInf.size more consistent with the MLton.size function, which
returns the number of heap words taken by an object.  Obviously, quite
a blunder.  It's not clear to me why or that MLton.IntInf.size should
be exported, given its rather delicate internal meaning.  Also, even
the size of a bignum is not what one would expect (it doesn't include
the sign word or the header).

So, I propose to change the size of a small bignum back to 1 and to
not export MLton.IntInf.size.

> It makes sense that we wouldn't see it until we had a space leak.  Note
> how initRes works:
...
> We always give the result the entire rest of the heap (not exactly the
> requested bytes).  

I'm not sure why we do this.  It doesn't seem necessary, since we
calculate the max needed size.  It would seem to be advantageous from
a debugging perspective as well.

A couple of other thoughts on making it easier to catch bugs like this
in the future.

* Could we put an assert into initRes (and other places) to catch this?

* Could we tell gmp to blow up if it does a realloc?