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

[Wesley W. Terpstra]

On Tue, Nov 4, 2008 at 2:12 AM, Nicolas Bertolotti
<Nicolas.Bertolotti at mathworks.fr> wrote:
> I have never encountered any issue with a too high value for minSize. If there were some, I guess they would have led to some unjustified "Out of memory" crashes and the only ones I have experienced experienced so far were caused by the fact the card/cross map was allocated after the heap itself (which is not the case anymore).

I have had minSize limit the obtainable memory in MinGW. To see these
interactions where desiredSize goes crazy you need to have the right
physical RAM and the right ram-slop.

The problem is that minSize is only a constant fraction of
desiredSize, and if desiredSize is too large the backoff gives up too
early, failing to grow the heap even though it could have. Another way
of addressing this would be to limit how quickly MLton can grow the
heap in one GC (to ensure that minSize never exceeds the current
size).

> Anyway, I spend my time trying to improve memory handling and there are still some open directions.
> I sent an e-mail about those (see http://mlton.org/pipermail/mlton/2008-September/030358.html).

In that email you state:

> Also, there are 2 very different situations which can cause a "createHeap" to fail:
> - not enough RAM to satisfy the allocation
> - not a big enough logical address range to satisfy the allocation

To my knowledge the first case never happens. "RAM" allocation only
fails if you are out of address space. This is why MLton's "ask for
the physical RAM" approach is necessary. This applies to both windows
and linux AFAIK. About the only useful information MLton can get about
how much memory it is able to use in a multi-process environment is
the resident size. It would be hard to use this information sensibly,
though, as you have to first try for a larger amount to determine the
resident size you get.