NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/cplus/12704

Internet Message Format | 1992-08-20 | 1.7 KB

Path: sparky!uunet!mcsun!corton!seti!goudurix.inria.fr!edelson
From: [e-mail] (Daniel R. Edelson)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Message-ID: <[e-mail]>
Date: 21 Aug 92 07:30:27 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: Daniel R. Edelson <[e-mail]>
Organization: INRIA -- Institut National de Recherche en Informatique et Automatique -- Rocquencourt, France
Lines: 21

In article <[e-mail]>, [e-mail] (Dave Gillespie) writes:
|> In article <boehm.714158406@siria> [e-mail] (Hans Boehm) writes:
|>
|> > Presumably you're really worried about pause times, and frequency of pauses.
|> > That's usually a valid concern, but in the presence of concurrent or
|> > incremental collection, things become less clear.  Even in the presence
|> > of generational collection, it may not buy you much if the short-lived
|> > objects are the ones that are being handled manually.
|>
|> Do you really think incremental or generational collectors are
|> feasible in C++?  I've never looked in the guts of one of these
|> collectors, but as I understand it they tend to depend on the
|> ability to move data around, and other things that a C++ collector
|> might not be able to get away with.  (C++'s use of pointers is so
|> unrestricted that it's a minor miracle it's possible to do garbage
|> collection at all...)

Plain old non-relocating garbage collectors can be
generational and/or incremental. This is sometimes overlooked
because of how common copying collectors are, and because most of
the first generational and incremental collectors were copying collectors.