[bitc-dev] Pools in lieu of GC
Jonathan S. Shapiro
shap at eros-os.com
Thu Mar 5 11:57:08 EST 2009
I think that exit claim assumes that all data transfer between
processes is performed by deep copy. This is a significant overhead,
and the linear typing behavior of Singularity is a very interesting
optimization on it.
Otherwise, I agree that the concept is useful and interesting.
On Thu, Mar 5, 2009 at 11:41 AM, Sandro Magi <smagi at higherlogics.com> wrote:
> Section 4.1 of :
> 4.1 Generational garbage collection of process-local heaps
> As mentioned above, when a process dies, all its allocated memory area
> can be
> reclaimed directly without the need for garbage collection. This
> property in turn
> encourages the use of processes as a form of programmer-controlled
> regions: a
> computation that requires a lot of auxiliary space can be performed in
> a separate
> process that sends its result as a message to its consumer and then
> dies. In fact, because
> the default runtime system architecture has for many years been the
> process centric
> one, many Erlang applications have been written and fine-tuned with this
> memory management model in mind.
>  http://user.it.uu.se/~kostis/Papers/scp_mm.pdf
> Jonathan S. Shapiro wrote:
>> On Thu, Mar 5, 2009 at 9:34 AM, Sandro Magi <smagi at higherlogics.com> wrote:
>>> Aside from type-safe memory systems , Erlang is a good example of
>>> explicit deallocation despite GC and memory safety. Creating and quickly
>>> destroying a separate process is a widely used pattern for prompt
>>> reclamation. If there's interest, I can dig up the reference to the
>>> Erlang memory management paper where they encouraged this pattern and
>>> designed memory management around it.
>> I agree that this is an interesting idea. It can be viewed as a
>> variant on the explicit named heaps idea.
>> Yes. I would appreciate a reference.
>> bitc-dev mailing list
>> bitc-dev at coyotos.org
> bitc-dev mailing list
> bitc-dev at coyotos.org
More information about the bitc-dev