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,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3498dd887729ed19 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Garbage Collection in Ada Date: 1996/10/29 Message-ID: #1/1 X-Deja-AN: 193158122 sender: news@organon.com (news) references: <199610181934142408603@dialup101-3-15.swipnet.se> organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-10-29T00:00:00+00:00 List-Id: In article Richard Riehle writes: > I find it odd that, in all this discussion of Garbage Collection, > we have not had any mention of System.Storage_Pools (ALRM 13.11). Actually, they have been mentioned several times - by me and a couple others. > Although I realize this is not the panacea for all garbage collection > problems, those who have suggested that the run-time executive would > have to wander blindly through all of a program's memory to determine > if some wayward pointer is lurking in some hidden corner, might consider, > when such issues are critical, setting up a storage pool controlled > via Ada.Finalization. Or (as has been mentioned) tying (sp?) instances of GC (possibly different flavors, where each could be more appropriate to the target type) to specific pools. Either implementation defined or possibly even user defined pools. > I, for one, am quite pleased that the designers of Ada 95 included this > capability, and sometimes wonder how many of my colleagues in the Ada > community have examined this feature closely enough to realize that it > is does have some virtue. It is a "god send" for those of us trying to put some GC like storage management into specific applications. This is the route that I ended up going down - finalization stuff is largely _irrelevant_. > While it is true that Root_Storage_Pool is derived > from Ada.Finalization.Limited_Controlled, this should not be > a particular hardship when control over the storage pool, > and automatic garbage collection are essential to a given design. The keys are being able to a) tie an access type to a pool b) define a type which cannot be allocated except by user defined constructor (limited type with unknown discriminants). This gurantees that a) is the only access type a client can use for the type. c) ability to redefine _new_ for the pool to a much lesser extent: d) ability to redefine manual deallocation for pool. Finalization for the pool could also be useful (though only in special cases) /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com