[bitc-dev] Pools in lieu of GC

[Jonathan S. Shapiro]

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 [1]:
>
>  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.
>
> Sandro
>
> [1] 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 [1], 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.
>>
>>
>> shap
>> _______________________________________________
>> bitc-dev mailing list
>> bitc-dev at coyotos.org
>> http://www.coyotos.org/mailman/listinfo/bitc-dev
>>
>
> _______________________________________________
> bitc-dev mailing list
> bitc-dev at coyotos.org
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
>