[MLton] Crash with 4GB ram

[Stephen Weeks]

> We have a crash of an mlton-20030716 generated executable when run on a 
> Sun with 4Gb RAM.

Thanks for the bug report Alain.

> One of our engineers suspects it is due to an overflow in the following 
> code.
...
> If totalRAM is equal to 4Gb, the above multiplication result will indeed 
> wrap around to zero.
> I suspect the same problem can occur with totalSwap, and in various 
> places in the code where totalRam+totalSwap is computed without 
> promotion to 64bits.

I agree completely.  On December 10, I checked in a fix for this bug
that changed the implementation of totalRam on Cygwin, Linux, and
Solaris:

static W32 totalRam (GC_state s) {
	W32 maxMem;
	W64 tmp;

	maxMem = 0x100000000llu - s->pageSize;
	tmp = sysconf (_SC_PHYS_PAGES) * (W64)s->pageSize;
	return (tmp >= maxMem) ? maxMem: (W32)tmp;
}

This keeps totalRam as 32 bits, but avoids the overflow I believe.  In
the same checkin I also eliminated totalSwap, and all of the sums of
totalRam and totalSwap.  Let me know if you are aware of other
potential overflows.

> Would it be worthwhile to change the type of totalRam and totalSwap to 
> unsigned long long, as well as to promote various computations in gc.c 
> to 64 bits ?

Yes.  My plan is to do this whenever we first port to a platform to
support 64 bit pointers.