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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://www.coyotos.org/mailman/listinfo/bitc-dev >> > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > > _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
