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,FREEMAIL_FROM, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e80a1497a689d8a5 X-Google-Attributes: gid103376,public From: "Vladimir Olensky" Subject: Ada and GC. Was: Re: Ammo-zilla Date: 1999/11/01 Message-ID: #1/1 X-Deja-AN: 543061403 References: <38120FAF.945ADD7D@hso.link.com> <7uutgd$87h$1@nnrp1.deja.com> <19991024.18033546@db3.max5.com> <38189268.43EB150F@mail.earthlink.net> <86ogdjtdwz.fsf@ppp-115-70.villette.club-internet.fr> <7vadsp$8q61@news.cis.okstate.edu> <1999Oct28.221910.1@eisner> <7vb3c4$8a21@news.cis.okstate.edu> <7vhg2n$7ht$1@nnrp1.deja.com> <7vht9i$a2g1@news.cis.okstate.edu> Organization: Posted via Supernews, http://www.supernews.com X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Newsgroups: comp.lang.ada X-Complaints-To: newsabuse@supernews.com Date: 1999-11-01T00:00:00+00:00 List-Id: David Starner wrote in message <7vht9i$a2g1@news.cis.okstate.edu>... >On Sun, 31 Oct 1999 13:26:48 GMT, Robert Dewar wrote: >>What for instance does it mean to do address overlays that >>reference the address of some object if the address of that >>object changes due to GC? I have no idea what a sensible answer >>to this question might be! > >Um, don't move it? Either pick a form of GC that doesn't move objects >(the Boehm conservative GC is one that almost becoming the standard >for free software, while GCC now uses a rather more sophisticated GC >internally that doesn't move stuff), or mark that object as immobile. Such problem exists only in the systems where everything is garbage collected. 1. In a system that gives you a choice to use TRACED or UNTRACED by GC objects just do not use TRACED objects if you don't want them to be moved by GC from one memory location to another. Ada 95 is a system that was designed to allow that. 2. Even if object is TRACED by GC it is possible to use a scheme that does not modify memory reference of the TRACED object that is visible to client. Such scheme may use Address Descriptor Table for indirect object reference within GC managed storage pool. This table is part of the GC storage pool manager. Each entry of such table could keep actual memory location of the referenced object and all the additional information that is needed to manage that object. ( e.g - Ref_Count field for simple reference counting GC). With such approach client knows only address of Address Descriptor Table entry for that particular object and the last one does not change when object is moved to the new memory location. There is nothing new in that. It is similar to the protected memory access in operating systems that run in a protected mode. Address of the object is just address of the descriptor table entry for that object and the system itself calculates actual memory address of the referenced object. What is more important such approach provides single_ point_ of_ access for TRACED by GC objects. This in turn could make many things more easy. Regards, Vladimir Olensky