[gclist] Re: PPC & GC, or GC and threads
Wed, 28 Jan 98 15:12:39 GMT
John R Levine <firstname.lastname@example.org> 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).
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/