Interesting, and consistent with what I'm seeing. I have an application that spawns a few thousand gen_servers. Each server instance initializes itself with a couple of mnesia queries, which may produce a lot of temporary data. The data that is eventually used as the gen_server's state is very limited, however. <br>
<br>In my test-setup, after initialization, the gen_server's just sit idle, and indeed seem to hang on to all heap-memory needed during initialization, leading to an out-of-memory error after creating only a few hundred processes. This is solved by forcing a garbage collection right after initialization, and probably also by using the fullsweep_after spawn option (which I still have to look into).<br>
<br>Thanks!<br><br><div class="gmail_quote">On Thu, Jan 22, 2009 at 1:33 PM, Christian <span dir="ltr"><<a href="mailto:chsu79@gmail.com">chsu79@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/1/22 Jeroen Koops <<a href="mailto:koops.j@gmail.com">koops.j@gmail.com</a>>:<br>
<div><div></div><div class="Wj3C7c">> Hi,<br>
><br>
> I have a simple question: In Java, it is guaranteed that, before an<br>
> OutOfMemoryException it thrown, all possible garbage collection has been<br>
> done. So, out of memory really means out of memory.<br>
><br>
> Does a similar guarantee hold for Erlang as well? Or is it possible for the<br>
> system to terminate with an out of memory error while garbage collection<br>
> could have freed more memory?<br>
<br>
</div></div>The later. This article could probably be worth to read:<br>
<br>
  <a href="http://www.lshift.net/blog/2008/10/31/erlangs-gc-only-runs-when-youre-running" target="_blank">http://www.lshift.net/blog/2008/10/31/erlangs-gc-only-runs-when-youre-running</a><br>
<br>
This led to the strategy: "This sounds reasonable - let's try<br>
hibernating after every message and see what happens." in this<br>
article:<br>
<br>
  <a href="http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-2/" target="_blank">http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-2/</a><br>
<br>
Garbage collection is per-process in the default memory model. As a<br>
strategy, long running processes should probably do only little work<br>
so they can be hibernated, and frequent work should probably be done<br>
in short lived processes so all resources are freed instantly when<br>
they die.<br>
</blockquote></div><br>