Re: Garbage Collection in Ada

[jsa@alexandria (Jon S Anthony)]

In article <Pine.GSO.3.95.961027083501.11380C-100000@nunic.nu.edu> Richard Riehle <rriehle@nunic.nu.edu> 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