[MLton] Crash fread(...) failed (only read 0) (Cannot allocate memory) during deepFlatten with MLton 20070826

[Nicolas Bertolotti]

Thanks for the answer.

I applied the patch and tried to rebuild.

Unfortunately, here is what I get now:
            deepFlatten starting
/bin/sh: line 33: 26073 Segmentation fault      ./lock-exec.x86-linux /tmp/MLton-build.lock /mathworks/GNB/hub/pst/build-tools-R2008b-testing/bin/mlton -cc-opt -D_UNIX -align 4 -verbose 2 -const 'TextIO.bufSize 65536' -const 'MLton.detectOverflow false' -runtime no-load-world -native-split 100000 -cc-opt -s -native-optimize 3 -cc-opt -O2 -cc-opt -funroll-loops -cc-opt -ffast-math -cc-opt -fomit-frame-pointer -cc-opt -fno-exceptions -cc-opt -fexpensive-optimizations -cc-opt -freg-struct-return -cc-opt -unroll-all-loops -target i686-pc-linux -link-opt -L. -link-opt -lz -output iabc-dfa.cx86-linux sources.mlb MLton_ffi.c $EXTRA_C_FILES

I am still investigating but you may know what's going on.

Nicolas

> -----Original Message-----
> From: Matthew Fluet [mailto:fluet at tti-c.org]
> Sent: Monday, April 21, 2008 2:00 AM
> To: Matthew Fluet
> Cc: Nicolas Bertolotti; mlton at mlton.org
> Subject: Re: [MLton] Crash fread(...) failed (only read 0) (Cannot
> allocate memory) during deepFlatten with MLton 20070826
>
> On Sun, 20 Apr 2008, Matthew Fluet wrote:
> > It occurs when the runtime system decides to page the heap to disk in
> order
> > to free up virtual memory to reallocate the heap at a larger size.
> > It will do this if the desired heap size is approaching the physical
> memory
> > limit, even if there is plenty of swap space available on the machine.
>
> Actually, this isn't right.  The runtime will attempt to page to disk only
> if creating a heap of the minimum size cannot be satisfied with the
> existing heap resident.
>
> It is curious that your program compiles without paging the heap to disk
> on the 4G machine, but not on the 2G machine, since the virtual memory
> address space should be the same on the two machines.  That is, the amount
> of physical memory shouldn't affect whether the virtual memory system is
> able to satisfy the request.
>
> Of course, starting off with different physical memory sizes means that
> different heap sizes will be realized by the compile on the two machines,
> so the point at which the paging occurs on the 2G machine may not
> correspond to any GC on the 4G machine.