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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b30bd69fa8f63cb2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-16 20:51:33 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!wn12feed!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!sccrnsc04.POSTED!not-for-mail Message-ID: <3EEE9024.8080101@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Garbage Collector [Was: C bug of the day] References: <1054751321.434656@master.nyc.kbcfp.com> <2111742.ktbtd1Oagc@linux1.krischik.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.62.164.137 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc04 1055821892 24.62.164.137 (Tue, 17 Jun 2003 03:51:32 GMT) NNTP-Posting-Date: Tue, 17 Jun 2003 03:51:32 GMT Organization: AT&T Broadband Date: Tue, 17 Jun 2003 03:51:32 GMT Xref: archiver1.google.com comp.lang.ada:39305 Date: 2003-06-17T03:51:32+00:00 List-Id: Robert A Duff wrote: > Also, in order to tell which objects in a given storage pool are > garbage, you have to know about all the pointers into that pool from > outside -- from other pools, from the stack, and from statically > allocated memory. The storage pool doesn't help there. > > Unless you're talking about so-called "conservative" garbage collection, > in which case you can use existing ones (see Boehm). > > In general, a good garbage collector requires cooperation from the > compiler. Even a so-called "conservative" GC requires that the compiler > avoid certain "tricky" optimizations. There are two issues here. First, if you want to build a "full" garbage collector, it needs to be compiler specific. Martin proposed a GNAT specific GC, so that is covered. Yes, new compiler versions might require updating the GC package. So it would be a good idea to contribute the package, and get it distributed with the GNAT compiler. The argument about "knowing" where the pointers are is to me, irrelevant. As far as I am concerned, a garbarge collection package for any compiler would require the compiler recognize that the storage pool required a special type of pointer. (Assume for the moment that their is a compiler specific pragma to use these special pointers, and of course the pragma argument is the storage pool, and it should be in the package that creates the storage pool type.) So the work required to implement a garbage collecter breaks into two parts (well three) parts: Decide what kind of special pointer is required. If I were doing it, I'd make the pointer, excuse me, access type class be a controlled type, and have the finalization operations keep a list of all the current pointer locations. Second, modify GNAT to support the special pointer type, and third implement the garbage collector. As I see it, the advantage of using a controlled access type would be that all the grody stuff could be "hidden" there, and the actual values would not need to be any larger than standard pointers. (But every copy of a pointer would create a new entry in the management table, when the table fills up--or the storage pool--garbage collection gets triggered.)