how to run out of memory: let binaries leverage the heap

[Matthias Lang]

davidwallin@REDACTED writes:

 > I just tried the attached program on my OS X system running R9B-0 with 
 > shared heap enabled I couldn't see any growth. Is this problem a 
 > non-issue on PPC systems or with shared heap ?

My post illustrated a disadvantage with one approach to memory
management in Erlang. It's independent of the CPU architecture and OS,
so you can't use it to make your boss buy you a PPC laptop ;-). 

It is likely that the shared heap is immune. It depends on whether or
not the total size of binaries affects the decision of whether to 
GC or not. I skimmed

   http://user.it.uu.se/~happi/publications/heap.ps
   http://user.it.uu.se/~happi/publications/heap.pdf

and I didn't see anything about how binaries are handled. But the
paper is worth a read anyway, it's very well written.

 > On a Linux box running with HiPE enabled (but no shared heap) I doo see 
 > an increase but after a couple of iterations this happens:
 > 
 > memshow process size: 6749120
 > memshow process size: 6749604
 > memshow process size: 6750088
 > memshow process size: 1768
 > memshow process size: 1768
 > ...
 > 
 > Any ideas what happens here ?

Probably the GC kicking in; my pathological example was chosen so that
the GC wouldn't kick in. What happens if you tweak the size of the
list comprehension in expand_heap/0, i.e. try some values lower than 75?

Matthias