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: Re: Ada and GC. Was: Re: Ammo-zilla Date: 1999/11/02 Message-ID: #1/1 X-Deja-AN: 543265915 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> <381DD258.B6B11153@averstar.com> 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-02T00:00:00+00:00 List-Id: Tucker Taft wrote in message <381DD258.B6B11153@averstar.com>... >Vladimir Olensky wrote: >> ... >> 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. > >By the way, don't you generally need to do reference >counting rather than tracing-based GC if you have some >traced and some untraced objects? If not, how do you deal with >pointers to traced objects that exist in untraced objects? >(Perhaps disallow at compile-time?) To be clearer I just used Modula-3 terminology that uses UNTRACED keyword to denote REF TYPES that are pointers that are not controlled by the GC. So in this context TRACED word denotes pointers that are controlled by GC and nothing more (it does not imply any GC mechanism). So I was saying that if one uses TRACED REF TYPE (default in M3) or in Ada "TRACED" ACCESS TYPE that means that this access type and operations with it are provided by the particular GC_storage_manager and that "TRACED" ACCESS TYPE is under full control of that GC manager. This GC_Pointer is of Ada.Finalization.Controlled type. GC manager provides Initialize, Adjust and Finalize operations for the "TRACED" ACCESS TYPE that it exports. Another operation is Create (GC_Ptr, Object_Type) that returns instance of that "TRACED" ACCESS TYPE which essentially is reference to the entry in GC Address Descriptor Table for the created object. That table entry may contain other information needed to implement particular GC management mechanism (it may be Reference_Count field for reference counting mechanism or may be something else). How pool management is implemented is private matter of that GC storage manager. So idea is that externally GC provides control over "TRACED" ACCESS TYPES via Initialize, Adjust and Finalize operations and internally over allocated objects referenced by "TRACED" ACCESS TYPES as well as dereferencing operations. Taking all that into consideration it does not matter where such "TRACED" ACCESS TYPE object (GC_Pointer) is located. Nulling-out such pointer or freeing any dynamically allocated object (which may be allocated by another GC manager) where such GC_Pointer is located will automatically reclaim storage when GC manager will see that there is no more references to the allocated object. As I mentioned in my other post when using such kind of storage pool controlled by GC via it's Address Descriptor Table actual storage pool may even be located on one or several remote machines that may act as Objects Storage Servers for many other machines. In this case local GC storage manager is a client of the remote GC_Storage_Server and we will have some kind of NETWORK_WIDE_VIRTUAL_GARBAGE_COLLECTED_MEMORY. May be I am wrong somewhere. I am not a big expert in GCs. I just let my imagination go where it wants to go. Regards, Vladimir Olensky