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

[Dave Lloyd]

John R Levine <johnl@iecc.com> asked:
> > Indeed. Our Algol 68 and Fortran 90 compilers were designed with an 
> > integrated precise garbage collector (of the mark and sweep variety). 
> 
> Are they intended to work in an environment with threads or asynchronous
> interrupts?  I would expect that the code generation is a lot easier if the
> compiler can assume that it controls when allocation or GC might happen. 
>
> The examples that provoked this discussion looked to me like they were of 
> the form:
> 
>         move xxx, R1
>         ; *** R1 now contains some but not all of the bits of a pointer
>         op   yyy, R1,R1
>         ; R1 now contains a valid pointer
  
Yes we do have async threads, but we are currently synchronised so that 
the program stops during GC - this is more because I didn't want to deal 
with objects changing during the process. And currently we arrange
that all threads stop cleanly - but that is more an issue of what the 
OSs will let us do to other threads. However we don't actually rely on 
this - the code generator arranges that the original pointer mentionned
(or something that ultimately points to it) is stacked somewhere earlier
in the frame or a parent of the frame. 

To clarify:  The reference map only contains entries for visible 
declarations and some longer lifetime intermediates such as the 
parameters to a procedure call or a vectored loop.  Anything that is 
provably held in older storage does not get entered in the map - usually
this means new allocations or anonymous storage such as the yield of a 
procedure call. Anything that is in the reference map will be shadowed 
on the stack.  Pointers or scrambled bits thereof in registers are 
never needed to find reachable storage.  Note that for arrays the 
reference map knows the bounds of an array so vectored loops will always 
have the whole array reference stacked somewhere prior to the loop.  

This will have to change come compaction - but even then all that should
be required is the reference map to chart reachable storage, and a 
secondary list of pointers (some of which may be in register) that must 
be relocated. My current preference is to have 'run-till' points
(probably branches or some subset thereof) when the registers with valid
pointers can be recorded as a bitset. It should not be hard to arrange 
that there are no partial values at such points. However this kind of 
thread synchronisation can be very clunky.

Unfortunately work on the GC is not a priority at the moment (it works
even if it can get a bit fragmented within the compiler itself).

Regards,
----------------------------------------------------------------------
Dave Lloyd                            mailto:Dave@occl-cam.demon.co.uk
Oxford and Cambridge Compilers Ltd    http://www.occl-cam.demon.co.uk/
Cambridge, England                    http://www.chaos.org.uk/~dave/