From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3498dd887729ed19
X-Google-Attributes: gid103376,public
From: Rick Hudson <hudson@tokay.cs.umass.edu>
Subject: Re: Garbage Collection in Ada
Date: 1996/10/18
Message-ID: <s29vic8cpge.fsf@tokay.cs.umass.edu>#1/1
X-Deja-AN: 190314584
references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se>
organization: Dept of Comp Sci, Univ of Mass (Amherst)
newsgroups: comp.lang.ada
Date: 1996-10-18T00:00:00+00:00
List-Id: <comp.lang.ada>


Hans-Juergen Boehm <boehm@mti.sgi.com> writes:
> 
> Rick Hudson wrote:
> > 
> > If GC is triggered only by an allocate then
> > one could roll forward the threads to a 'gc' point. This greatly 
> > reduces the amount of table information needed.
> > 
> 
> This works well if you can reliably and reasonably quickly advance
> threads to the next GC point without forcing them to execute code at the
> GC point when they don't need to stop.  In some systems that's easy.  In
> some that's hard.  The thread systems I've used can't easily do that.


The slickest idea I've heard of, I think it was from Greg Nelson, was to have
a routine that clones the code from where the thread stopped to the gc safe
point. The routine would execute the cloned code instead of the original code
and then halt at the gc safe point. The thread would be resumed in the normal
code. This technique will give you no normal execution overhead.

- Rick Hudson