[MLton] Segmentation fault in 32 bit mode on a 6 GB machine with ram-slop 0.85

[Wesley W. Terpstra]

On Sun, Nov 9, 2008 at 9:55 PM, Matthew Fluet <fluet at tti-c.org> wrote:
> I think that the best solution is for sizeofHeapDesired to return a size
> that will not overflow when aligned and will not overflow when combined with
> the card/cross map size.  This can be handled using the architecture virtual
> address space limit -- irrespective of any OS specific limits.

You mean using ADDRESS_BITS? Seems reasonable.

> Indeed, I
> think the whole question of sizing policies that take into account RAM, OS
> specific factors (like contiguous address space), etc. should be entirely
> separate from avoiding overflow of size computations.

In fact, I now think it's unnecessary to take any action. As we
discussed earlier on googletalk, the phenomenon I saw was not caused
by bad decision making in MLton's GC. It seems to me now that no
action is required to take contiguous address space in the OS under
consideration. The current mremap emulation suffices to grow up to the
achievable limit (and/or stop earlier if more is not requried).

> Of course, there are probably a number of places in the runtime where sizes
> could overflow.  I would be particularly worried about things like array
> allocation and stack growth, which could generate a large request.

You're worried about a single array which almost exceeds 4GB and is
then aligned to 4GB? Since it's completely impossible to satisfy these
requests, couldn't we just bail out immediately with an out-of-memory
error?