Re: Ada GC and a bunch of other stuff

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


>Incidentally what to Conservative GCs do about this? Surely they have
>the same problem: a sole copy of a pointer may have been sent across
>the Net to a machine in Finland (much poorly designed C uses the
>integer equivalent of the internal pointer as the external handle to a
>data structure).
>Similarly there may be unregistered threads of
>execution that are capable of modifying the GC arena behind the
>sweep. Many OS-supplied thread mechanisms do not allow all threads
>within your process to be enumerated - some even allow threads to be
>slept and woken from other processes.


Our GC assumes that if you send a pointer to Finland, you also
maintain a local copy. This isn't much of a problem, since pointers
get sent to Finland (or written to a file) from a small number of
places in the code, if any, and it's easy enough to register them on
the way out. It should even be possible to do this by replaing the
standard C output routines, though we don't currently do that.


We also assume that there are no unregistered threads of execution.
If the thread package doesn't provide the right primitives, then the
garbage collector may have to intercept thread creation calls, etc.
We currently do this for Solaris threads. Our current solution does
require recompiling code that forks a thread, or does something
similar. Yes, this is ugly. I'm all in favor of fixing the thread
packages.


I'm not particularly concerned about another process restarting a
thread. Any process that does that should expect the target proces to
crash, since it's arbitrarily violating my assumptions about
synchronization. That's independent of garbage collection. It's
equivalent to another thread changing one of my register values, which
a good debugging interface will also let you do with sufficient
privileges.


Should we move this to gclist@iecc.com?


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

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