[gclist] Re: PPC & GC, or GC and threads

[Jan-Willem Maessen]

Dave Lloyd <Dave@occl-cam.demon.co.uk> writes:
> The compiler tracks all references statically and ensures that 
> *somewhere* there is a root pointer for all objects being manipulated. 
> This root pointer may well be in an outer procedure frame - our calling
> convention includes the rule that references passed to procedures must 
> be recorded in the ref map.

If I understand this correctly, this means that you can retain dead
data passed into a long-running procedure.  In an language like
Fortran I would expect this to be a problem.  I'm assuming you have
decided it isn't, or have taken steps to avoid it?

On another note, more relevant to the discussion of multithreading, I
note that the collectors under discussion seem (by and large) to
assume that collection can happen safely at arbitrary times during
execution.  Will collection need to be atomic, at least long enough to
establish reachable register state?  If so, how is this atomicity
established?  If not, why not?  (I fear I may have simply
misunderstood a fundamental assumption here.  Perhaps my confusion is
really a question about fundamental threading support, or a
thinly-veiled complaint about the inadequacy of POSIX threads in the
face of garbage collection.)

I am also curious when it becomes reasonable to expect some
cooperation from the allocator itself.  For example, when the
allocation rate is sufficiently high it is reasonable to suspend
threads as they allocate, and then to invoke the collector when all
threads are thus suspended.  Have tradeoffs such as this been well
studied?  Coming from the functional languages end of the world (I
wrote the parallel Haskell collector) we take a high allocation rate
for granted; however, there is some concern that "really good"
generated code may allocate infrequently enough to cause starvation.
Solid numbers would certainly put my mind at rest.

					-Jan-Willem Maessen
					pH compiler hacker
					jmaessen@mit.edu