[MLton-user] out of memory

Sean McLaughlin seanmcl at gmail.com
Tue Jun 1 11:28:26 PDT 2010


Hello,

  Both solutions you proposed worked.  Oddly I think, may-page-heap true was
significantly faster than -drop-pass deepFlatten.  If you like, you can grab
my program at

http://github.com/seanmcl/imogen.git

In case you don't get to it for awhile, the commit you want is

6f6d8f6b224a3b38aa1f<http://github.com/seanmcl/imogen/commit/6f6d8f6b224a3b38aa1fc259a7dc6b8149ef1c62>

Once you download the sources, you need to set the environment variable
IMOGEN_HOME, then cd to modal-prop, then run make.

Best,

Sean


On Tue, Jun 1, 2010 at 1:40 PM, Matthew Fluet <matthew.fluet at gmail.com>wrote:

> On Tue, Jun 1, 2010 at 12:18 PM, Sean McLaughlin <seanmcl at gmail.com>
> wrote:
> >   I'm getting an out-of-memory error from MLton, though I have 4GB of
> > memory.  I don't understand it because my program
> > is significantly smaller than the MLton source.  Is there a way around
> this?
> >
> >      ssa2Simplify starting
> >         typeCheck starting
> >         typeCheck finished in 0.55 + 0.00 (0% GC)
> >         deepFlatten starting
> > Out of memory.  Unable to allocate heap with 1,192,034,304 bytes.
>
> There are some performance issues with the deep flatten pass, where it
> consumes an excessive amount of memory, as you observe.  See some
> notes at the end of
>  http://mlton.org/DeepFlatten
>
> The simplest course of action is to compile with "-drop-pass deepFlatten".
>
> You are also running up against the maximum amount of contiguous
> memory that you can get from the operating system.  Due to MLton's
> heap resizing policy, it can sometimes grow one heap so large that it
> can't allocate another (larger) heap.  You can also try compiling with
> "@MLton may-page-heap true", which will allow MLton to write the heap
> to a temporary file, free the heap, and then try to allocate a new
> heap in a less constrained virtual address space.  MacOSX should be
> able to give you about 2.1GiB of heap.  But, if DeepFlatten is
> seriously over allocating, then that might not help.
>
> In any case, if you can send a snapshot of the program that
> demonstrates the out-of-memory, then it might help to have another
> example of the issue.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton-user/attachments/20100601/ffb8da51/attachment.html


More information about the MLton-user mailing list