[MLton] Memory problems with latest CVS?
Matthew Fluet
fluet@cs.cornell.edu
Sat, 11 Sep 2004 09:58:29 -0400 (EDT)
> So, I propose to change the size of a small bignum back to 1 and to
> not export MLton.IntInf.size.
Sounds good. MLton.size does the "right thing" on an IntInf.int, correct?
If so, there doesn't seem to be any reason for MLton.IntInf.size to be
exported.
> > 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?
I was thinking of putting an assert in setFrontier, which would assert
that the new frontier was never more than the old frontier + bytes.
I don't think an assert in initRes really helps -- we would need
to duplicate the logic for needed size (in which case its not really an
independent test).
> * Could we tell gmp to blow up if it does a realloc?
That would probably be useful.