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: Hans-Juergen Boehm Subject: Re: Garbage Collection in Ada Date: 1996/10/17 Message-ID: <3266B6F6.167E@mti.sgi.com>#1/1 X-Deja-AN: 190151918 references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se> cc: boehm content-type: text/plain; charset=us-ascii organization: Silicon Graphics Inc., Mountain View, CA mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.0S (X11; I; IRIX 6.2 IP22) Date: 1996-10-17T00:00:00+00:00 List-Id: Rick Hudson wrote: > > bobduff@world.std.com (Robert A Duff) writes: > > > > In article <3265BD97.41C6@mti.sgi.com>, > > Hans-Juergen Boehm wrote: > > >For systems I've seen it does inhibit some optimizations, ar least to > > >the extent that proper use of a conservative collector inhibits > > >optimizations. Especially in multithreaded systems, there must be a > > >recognizable pointer to every accessible object at every program point > > >at which a GC might occur. Often this is between every pair of > > >instructions. In a nonconservative system you could generate > > >arbitrarily complex tables to allow reconstruction of those pointers. > > You could but you don't have to. 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. -- Hans-Juergen Boehm boehm@mti.sgi.com