On Thu, Mar 5, 2009 at 10:26 AM, Jonathan S. Shapiro <[email protected]> wrote: > You don't GC at all at the VAT layer, so explicit reclamation of vats > is orthogonal to GC questions.
Even among vats on different machines communicating over CapTP, we do distributed acyclic GC. This collects most distributed garbage, but fails to reclaim unreferenced distributed loops. For vats within the same process, we do much better. From section 14.3 of my thesis: > For this purpose, E implementations allow several vats to run in a single > address space. > Between vats within the same address space, E provides a special purpose comm > system, > the BootCommSystem, similar in semantics to Pluribus, but implemented by > thread-safe > pointer manipulations rather than serialization. The BootCommSystem’s > important op- > timization is simply that it passes data—any message argument accepted by the > Data > guard—by pointer sharing rather than copying. Since data is transitively > immutable, > and since a copy of data is indistinguishable from the original, this > optimization is semantically > transparent. It enables large immutable structures to be cheaply shared. Among vats within the same process, held together by the BootCommSystem, GC is process-wide. However, the vats are individually still reclaimable. For both Kevin E-on-CommonLisp implementation and the E-on-Java implementation, the process-wide GC is provided for us by the underlying language. Terminating a vat causes all pointers into the vat to be dropped, allowing the process-wide GC to actually reclaim its storage. When Data (as defined above) is directly shared between vats, it is retained so long as it is reachable from any non-terminated vat. -- Text by me above is hereby placed in the public domain Cheers, --MarkM _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
