GC across address spaces (WAS: Adding garbage collection to C++)

>bill@amber.ssd.csd.harris.com (Bill Leonard) writes:
>>[How to garbage collect multi-threaded programs where some pointers to
>> shared memory are kept in per-thread private storage]


tmb@idiap.ch writes:
>[You don't need "garbage collection only if specifically asked for.
> Just retain a pointer to the object in the address space of A.
> In fact, you can encapsulate this behavior nicely inside your "send"
> procedure.]


One of the big reasons for using GC is that it frees the programmer from
managing object lifetimes explicitly. Some parallel programming
practicioners say (I think correctly) that figuring out lifetimes is, in
general, substantially harder with parallelism than without.


Explicitly retaining a pointer will solve the problem but defeats one of
the reasons for having GC in the first place. Now the programmer of
address space A must decide when address space B has finished with the
memory and the pointer in A can be destroyed. Some of the mental overhead
can be masked by various protocols, but the pointer still comes at the
programmer's expense.


The technique of ``keeping a pointer'' to prevent GC is good. So is
promoting storage from gc'able to non-gc'able. Ideally, you keep a
uniform programming model and the underlying implementation is optimized.
In practice, you probably keep a uniform programming model but the
implementors of libraries, stubs, etc., are forced to worry about the
performance issues and choose implementations accordingly.


    ;-D on ( Sharing memory with every process that's shared it ) Pardo
--

Return to the comp.compilers page.
Search the comp.compilers archives again.