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: Nick Roberts Subject: Re: Ada GC (was Ammo-zilla) Date: 1999/11/04 Message-ID: <3820CF33.81C062E1@callnetuk.com>#1/1 X-Deja-AN: 544247049 Content-Transfer-Encoding: 7bit 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> <7vkjea$b34$1@nnrp1.deja.com> <7vncgr$bpg$1@nnrp1.deja.com> X-Original-NNTP-Posting-Host: da130d39.dialup.callnetuk.com X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Trace: 4 Nov 1999 05:10:29 GMT, da130d39.dialup.callnetuk.com Organization: Computer Consultant MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-11-04T00:00:00+00:00 List-Id: Vladimir Olensky wrote: > ... > This restriction could be done using language support for GC. > Let's suppose that we have additional keyword TRACED > that applied to the ACCESS TYPES controlled by GC. > (This TRACED ACCESS TYPE could be bound > to particular GC using standard Ada construct: > for T'Storage_Pool use Ada.GC.GC_Name_Storage_Pool). > > When access type is declared to be traced compiler should > not allow any unchecked conversions with that type in standard > mode. > In may allowed only using additional pragmas. Rather than introducing a new reserved word into the Ada syntax, I think all that would be necessary would be for a new standard (abstract) pool type to be defined, derived from Root_Storage_Pool, called Root_Managed_Pool, say. Managed (garbage collecting) pools would all be derived from this type. I think Root_Managed_Pool would have at least one extra primitive operation, to induce a garbage collection and/or object compaction cycle. In order to cause objects referenced by a certain access type to be allocated into a managed pool, one would simply declare a Storage_Pool representation clause for the access type, naming an object of the appropriate managed pool type. Notice how this leaves implementations free to choose to provide garbage collection by default or not (or to select this by pragma, compiler switch, or other option). It would then be the responsibility of the compiler to ensure that all objects of this access type were 'traced', as Vladimir puts it. This means, in practice, that: a type descriptor for the access type must be entered into a 'type descriptor table'; every single object of the access type must be entered into a 'frame object table'; every instance of a value of the access type being loaded into or saved out of a register must be entered into a 'register loading table'; every compound type which can contain one or more values of a traced type is also traced (and so on recursively). The three tables would form part of the static data of the program, and would enable managed pools to determine the size and alignment of every object they contain, and to move those objects about in memory, correcting variables and registers as necessary. In addition, the compiler must provide facilities (to the pool managers) for identifying and freezing those tasks using a managed pool, for reading from and writing to the stack frames and register sets of those tasks, etc. (Or, to put it in simpler terms, no-one should be in doubt as to the complexity of adding GC, nor, for that matter, to the possibility of doing so.) It may well behove a compiler to issue a serious warning for any use of unchecked conversion, deallocation, or access for any traced type. But ultimately, as ever, if the user (Ada programmer) screws up, after having been so warned, he or she only has himself or herself to blame. It would undoubtedly be very useful (and not overly difficult, I think) for the implementor of a managed pool to provide an alternative implementation or mode which (sacrificing some efficiency perhaps) provided various (extra) profiling and debugging facilities relating to the use of the pool. It would be particularly incumbent upon the implementors of managed pools to make special efforts to ensure the correctness of their implementations, since the results of a garbage collector going wrong are always likely to be particularly unfortunate. -- Nick Roberts Computer Consultant (UK) http://www.callnetuk.com/home/nickroberts http://www.adapower.com/lab/adaos