[MLton] Memory problems with latest CVS?

Matthew Fluet fluet@cs.cornell.edu
Fri, 10 Sep 2004 10:24:24 -0400 (EDT)


> Certainly realloc should never be called (except maybe by the gcd code that
> Stephen put in).  It could be that I just blew the calculation I make of what
> the maximum space needed is, but it would be pretty strange that it only
> showed up now.  I'll take a look at what is going on.
> Is the test program ever doing a gcd?

No, there are no gcd's.  I'll also note that at

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

It makes sense that we wouldn't see it until we had a space leak.  Note
how initRes works:

static inline void initRes (__mpz_struct *mpzp, uint bytes) {
	struct bignum *bp;

	assert (bytes <= gcState.limitPlusSlop - gcState.frontier);
	bp = (bignum*)gcState.frontier;
	/* We have as much space for the limbs as there is to the end of the
         * heap.  Divide by 4 to get number of words.
         */
	mpzp->_mp_alloc = (gcState.limitPlusSlop - (pointer)bp->limbs) / 4;
	mpzp->_mp_size = 0; /* is this necessary? */
	mpzp->_mp_d = bp->limbs;
}

We always give the result the entire rest of the heap (not exactly the
requested bytes).  So, chances are, there are at least the 24 bytes we
normally need to multiply two "small" big-nums.  But, when there is the
space leak, we are running "close" to limit for a lot of the time.  It
also explains why it is so hard to reproduce -- you need to be hitting one
of these sorts of multiplications when there is less than 24 bytes
left in the heap.