There were a number of designs discussed in the paper, and in Wilhelmsson's thesis, including a hybrid heap architecture where messages are speculatively allocated to a shared global heap. IIRC, this is the design Erlang uses, so it doesn't incur message copying overhead in the general case, but process exit may leave some messages in the shared heap to be collected later. I don't recall the accuracy of the speculation at the moment.
Sandro Jonathan S. Shapiro wrote: > 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 > _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
