[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:
>> What platform is this?
> The platform is Linux (64 bit OS but my binary is compiled in 32 bit mode).

Ahh, the 64bit must explain how you got > 3G. The kernel must not be
mapped in the high 1G as usual for 32bit mode. This also explains an
open question about why only some systems exhibit problems; machines
with large amounts of RAM are probably using a 64bit kernel.

>> I pointed out a related problem on Oct 14
>> <http://mlton.org/pipermail/mlton/2008-October/030413.html>:
>> > Another thing I've noticed is that MLton's estimate of the available
>> > RAM can trick it into making bad choices for the heap size. You can
>> > only possibly get 1.2G on cygwin, but MLton thinks it should be able
>> > to get an amount = physical ram. It sets the minSize and desiredSize
>> > both too high and is the remap then fails. However, if it had a less
>> > aggressive minSize, it could have allocated another 300MB. I'm not
>> > sure what to do about this. Perhaps cap the physical RAM based on the
>> > platform?
>>
>> I had hoped to generate some discussion, but it seems no one was
>> listening. :-)
>
> As far as I know, the fact that desiredSize can be too high is not a big issue. After a number of backoffs, mmap/mremap succeeds and the only consequence is that createHeap/remapHeap runs a bit slower.

If the desiredSize never exceeded 3/4G, you wouldn't have had the heap
size wrap around like you did. MLton would never have attempted to
grow the heap beyond the size of a 32bit int. Two birds with one
stone.

What I am proposing is to take max(physicalRam * ram-slop, cap) as the
limit for desiredSize. For 64bit kernel, 32bit linux, set the cap to
say 3.8G to prevent wrapping around the size of an unsigned integer.

> Also, in multi-core context, when 2 processes are running, it is sometimes more efficient to suspend the execution of one process after paging its heap to disk. Then, the second process won't swap and finish the job in a shorter amount of time.

Managing memory between processes isn't really MLton's job, but the
user's. Don't run two programs who need more combined memory than you
have. :-) Or set ram-slop 0.5.