Hi Matthew,<br><br>Thanks for the quick response. With "-drop-pass deepFlatten" I was able to complete x86 codegen,<br>after which gcc choked on the generated C file, i.e., this was unable to complete on my machine<br>
due to insufficient memory:<br><br> Compile and Assemble starting<br> gcc -std=gnu99 -c \<br> -I/Users/nkidd/sw/mlton-20100608-1/usr/local/lib/mlton/targets/self/include \<br> -I/Users/nkidd/sw/mlton-20100608-1/usr/local/lib/mlton/include -O1 \<br>
-fno-common -fno-strict-aliasing -fomit-frame-pointer -w \<br> -I/usr/local/include -I/opt/local/include -I/sw/include -m32 \<br> -fno-strength-reduce -fschedule-insns -fschedule-insns2 \<br> -malign-functions=5 -malign-jumps=2 -malign-loops=2 -o \<br>
/var/folders/Ni/NireuwJ4EqeNlBbesdtkj++++TI/-Tmp-/fileRhFG4a.o \<br> /var/folders/Ni/NireuwJ4EqeNlBbesdtkj++++TI/-Tmp-/file8ibMpc.82.c<br><br>After moving to a linux machine with more memory (5g) I was able to finish the compilation. I might suggest adding to the TODO list generating multiple, smaller .c files to keep gcc ;) (I assume that you are not relying on gcc's optimizer too much at that point in the compilation.)<br>
<br>I'll work on getting the sources to you.<br><br>Thanks again,<br>Nick<br>Thanks,<br>Nick<br><br><div class="gmail_quote">On Tue, Dec 7, 2010 at 10:42 AM, Matthew Fluet <span dir="ltr"><<a href="mailto:matthew.fluet@gmail.com">matthew.fluet@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">On Mon, Dec 6, 2010 at 5:52 PM, Nicholas Kidd <<a href="mailto:nakidd@gmail.com">nakidd@gmail.com</a>> wrote:<br>
> Hi MLton developers,<br>
><br>
> I have a program that MLton compiles just fine without profiling turned on;<br>
> however, when profiling is enabled via -profile {time,alloc,count}, MLton<br>
> runs out of memory in the deepFlatten phase. I haven't yet tried, but I<br>
> imagine disabling the deepFlatten pass will allow for compilation to<br>
> succeed. Is there a better alternative? What would be the best way to debug<br>
> the memory usage? I.e., what information can I gather that would be useful<br>
> in debugging the issue?<br>
<br>
</div>There are some known performance issues with the memory usage of<br>
DeepFlatten, which have never been fully investigated. See some notes<br>
at the end of<br>
<a href="http://mlton.org/DeepFlatten" target="_blank">http://mlton.org/DeepFlatten</a><br>
Profiling tries to impact the optimizations as little as possibly, but<br>
in some instances, like your program, things are changed enough that<br>
it triggers the memory explosion. Compiling with "-drop-pass<br>
deepFlatten" is probably the best course of action. As for<br>
information useful for debugging the issue, the program that triggers<br>
the memory usage would be helpful. It is on a long list of TODOs to<br>
investigate the RefFlatten and DeepFlatten memory issues.<br>
<div class="im"><br>
> Some initial information that might be helpful:<br>
><br>
> :: Machine is a macbook pro 2.8 Ghz with 4GB of memory running OS 10.6.5<br>
><br>
> :: mlton outputs "MLton 20100608 (built Tue Jun 8 13:10:24 EDT 2010 on <a href="http://fenrir.cs.rit.edu" target="_blank">fenrir.cs.rit.edu</a>)"<br>
><br>
> :: I'm using the 32bit version of MLton (though the same behavior was observed with the 64bit executable, it just chewed up a lot more memory)<br>
><br>
> :: A `wc -l *.sml` returns 43357<br>
><br>
> :: Successful command line is as follows:<br>
> mlton -runtime 'gc-summary' -profile no -output athena-profile=no -verbose 2 athena.mlb > build-profile=no.txt 2>&1<br>
><br>
> :: Unsuccessful command line:<br>
> mlton -runtime 'gc-summary' -profile alloc -output athena-profile=alloc -verbose 2 athena.mlb > build-profile=alloc.txt 2>&1<br>
><br>
> :: Last few lines of build-profile=alloc.txt<br>
> ssa2Simplify starting<br>
> typeCheck starting<br>
> typeCheck finished in 0.32 + 0.00 (0% GC)<br>
> deepFlatten starting<br>
> Out of memory. Unable to allocate heap with 1,192,034,304 bytes.<br>
><br>
> That final heap size looks small doesn't it?<br>
<br>
</div>A little small, but consistent with MLton's heap resizing policy: it<br>
can sometimes grow one existing heap so large that it can't allocate<br>
another (larger) heap. You can also try compiling with "@MLton<br>
may-page-heap true", which will allow MLton to write the heap to a<br>
temporary file, free the heap, and then try to allocate a new heap in<br>
a less constrained virtual address space. MacOSX should be able to<br>
give you about 2.1GiB of heap. But, if DeepFlatten is seriously over<br>
allocating, then that might not help.<br>
</blockquote></div><br>