Re: Ada GC and a bunch of other stuff

boehm@parc.xerox.com (Hans Boehm)
27 Feb 1996 16:32:35 -0500

          From comp.compilers

Related articles
[5 earlier articles]
Re: Ada GC and a bunch of other stuff boehm@parc.xerox.com (1996-02-14)
Re: Ada GC and a bunch of other stuff dave@occl-cam.demon.co.uk (Dave Lloyd) (1996-02-16)
Re: Ada GC and a bunch of other stuff hbaker@netcom.com (1996-02-17)
Re: Ada GC and a bunch of other stuff boehm@parc.xerox.com (1996-02-21)
Re: Ada GC and a bunch of other stuff boehm@parc.xerox.com (1996-02-21)
Re: Ada GC and a bunch of other stuff dave@occl-cam.demon.co.uk (Dave Lloyd) (1996-02-23)
Re: Ada GC and a bunch of other stuff boehm@parc.xerox.com (1996-02-27)
| List of all articles for this month |

From: boehm@parc.xerox.com (Hans Boehm)
Newsgroups: comp.compilers
Date: 27 Feb 1996 16:32:35 -0500
Organization: Xerox Palo Alto Research Center
References: 96-02-113 96-02-210 96-02-269
Keywords: GC, parallel

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)
--


Post a followup to this message

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