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: <3266C457.446B@mti.sgi.com>#1/1 X-Deja-AN: 190180137 references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se> <199610132138291604607@dialup101-6-14.swipnet.se> <19961014115513529729@dialup105-2-16.swipnet.se> <199610162305033003135@dialup100-4-3.swipnet.se> <3265BD97.41C6@mti.sgi.com> 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: Robert Dewar wrote: > > HJB says > > "It could require the existence of a collector, and a (partially) > conservative collector may well be the most viable implementation > strategy." > > What would it mean to sanction the existence of a collector. As I noted > earlier, at most it could mean that you provide for the possibility of > unreachable blocks disappearing, but there are several problems here: > > 1. Since you only *allow* such collection, completely ignoring the requirement > is a valid semantic interpretation. > > 2. Since you can only collect unreachable blocks, the removal of them has > null semantics in any case, unless you allow finalization to happen at > unpredictable points, a nasty thought! > > 3. You cannot require blocks to disappear, since if you have conservative > collectors in mind they do not guarantee to free even a single block in > a given program. > > Conservative collectors are a clever idea, and are a clever response to > dealing with wanting GC in an implementation that does not otherwise > provide GC, but I don't see that the concept has any relevance in language > design. This is an interesting issue. Language specs generally do not say anything specific about space usage. Hence you can't formally define what it means to have a garbage collector (except possibly for asynchronous finalization, which is a different issue). This is independent of whether you have a conservative or traditional collector in mind. Nonetheless, I think language specs should contain informal statements about whether GC is expected, since you can't reasonably program without such an understanding. The use of a conservative versus traditional collector is mainly an implementation, and not a language design issue. It does have some minimal impact, since it makes it possible to garbage collect a language with C style unions and an address-of operator as in C. I don't know of any other feasible techniques. -- Hans-Juergen Boehm boehm@mti.sgi.com