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,fd63afa4dc364b7e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-03-17 01:38:53 PST Path: nntp.stanford.edu!newsfeed.stanford.edu!canoe.uoregon.edu!logbridge.uoregon.edu!newsfeed.direct.ca!look.ca!newsfeed.bc.tac.net!news.bc.tac.net!not-for-mail Sender: blaak@TORUS Newsgroups: comp.lang.ada Subject: Re: Better support for garbage collection References: <98m938$2iod0$1@ID-25716.news.dfncis.de> From: Ray Blaak Message-ID: Organization: The Transcend X-Newsreader: Gnus v5.6.42/Emacs 19.34 Date: 15 Mar 2001 09:56:38 -0800 NNTP-Posting-Host: 208.181.209.61 X-Complaints-To: news@bctel.net X-Trace: news.bc.tac.net 984679022 208.181.209.61 (Thu, 15 Mar 2001 09:57:02 PST) NNTP-Posting-Date: Thu, 15 Mar 2001 09:57:02 PST Xref: nntp.stanford.edu comp.lang.ada:91488 Date: 2001-03-15T09:56:38-08:00 List-Id: "Nick Roberts" writes: > type Object_Token is new Address; I would suggest something like this instead: type Object_Token is private; function AddressOf(Token : Object_Token) return System.Address; function TokenOf(Storage_Address : System.Address) return Object_Token; That way you can still easily convert to addresses and back, and yet the implementor has a lot more freedom in deciding how to represent a token. Does a token represent the address of an object allocated with this pool? If so, after a compaction, aren't all tokens for an object potentially invalid if an object is moved? Perhaps some sort of indirection handle concept is needed. Also, since regularly allocated objects can still refer to reposition-pool objects, garbage collection will still need to interact all dynamically allocated memory. If an object is still reachable by *any* path, then it cannot be released yet. If this is not the case, it seems to me that manual maintenance of allocation/locking is still required, defeating the purpose of GC. Given this, the utility of such a package is questionable to me. If GC is present, it is either completely on or completely off. Perhaps all that is really needed is some way to invoke compaction/collection directly, and the ability to lock/unlock objects explicitly, to allow for the occasional manual intervention. Otherwise, the standard allocators and access assignments can do all of the GC work, as they would need to do anyway. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul.