Re: Ada GC and a bunch of other stuff

Dave Lloyd <dave@occl-cam.demon.co.uk> writes:


>I should point out that many of David Chase's observations on the
>interactions between a GC and an optimiser are borne of the way
>conservative GCs go to work.


...


>Preemptive multi-threading is hairier still depending on one's
>strategy. We chose to use semaphores to force all processes to
>synchronise before a GC. This may cause a longer latency in the
>process that triggered the GC but there is a gap in the process's view
>of synchronisation with the GC in which compute which doesn't interact
>with the GC or GC-owned pointers can be hidden (e.g. a vector product
>of reals). The analysis is tractable for many useful cases in Algol 68
>and PCF-Fortran, but I have yet to get this far.


I don't understand this. Clearly you can't mean that you wait for all
other threads to try to acquire a lock? Even if you handle threads
blocked on IO correctly, this leaves you with a completely unbounded
wait for compute-bound threads that don't synchronize, negating much
of the advantage of preemptive multi-threading.


One of the nice properties of a collector using a conservative stack
traversal is that, assuming cheaply enforcable safety properties on
the generated code, you can stop threads at any point for GC purposes.
With a nonconservative collector, you need to set up GC safe points
inside every loop. This may still be cheap if you have a facility for
single- stepping threads.


Hans-J. Boehm
(boehm@parc.xerox.com)
--

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