Re: Ada and GC

Regarding garbage collector extensions from Intermetrics for Ada 95:


On 31 Jan 1996, Robert Dewar wrote:
> {Ada 83 didn't have GC for a variety of reasons and ...]
>
> I actually suggested during the Ada 95 design that we require GC in
> the context of the Information Systems annex, but even that came
> nowhere near to achieving consensus.
>
> I would certainly expect someone to add GC to GNAT at some point
> (there is already a GC implementation of Modula-3 that works on the
> VAX with GCC).


As Scott Leschke suggested, we have an initial draft of an Ada95
binding to ODMG that I would be happy to hear comments on. It is at
http://www.inmet.com/pob.html. Our binding does not depend on tags,
but rather is based on another Ada language specific feature: storage
pools. I have put a brief overview of the binding at the end of this
message.


--------------- ODMG Ada95 binding overview


The Ada binding for the ODMG standard object-oriented database model
uses Ada's unique concept of storage pools as the basis for a
persistence mechanism that is independent of type. Unlike the
standard C++ binding, which requires that all persistence capable
types have a common ancestor type, the Ada binding allows any type to
be made persistent. This additional flexibility allows existing types
to be made persistent without modifying their inheritance hierarchy.


The persistence of an object is determined by the storage pool it is
managed by. Each heap allocated object in Ada is allocated within a
storage pool. The storage pool used is determined by the access type
(pointer type) that is used for the new object. The storage pool for
an access type handles the allocation and deallocation of its
instances. By using separate storage pools for each access type, the
compiler may use a different representation of pointers depending on
the storage pool. With this facility, it is possible to use
persistent object identifiers (OIDs) or some other indirect reference
as the pointer type for persistent objects without changing the way
these objects are accessed in the code


The current storage pool mechanism is not quite strong enough to
handle persistent objects, since there is no hook for dereferencing
access values. We define a new language attribute for specifying the
storage manager of an access type. The storage manager type is a
subtype of the storage pool type, but it also has operations for
dereferencing. The storage manager attribute is not specific to
handling persistence, but may also be used to create garbage collected
storage pools. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^


One potential concern is that this binding requires a modification to
the compiler. There are two answers to this concern. The first is
that we also define an alternate version of the binding which is the
same as the regular binding, except that explicit dereferencing calls
need to be made. The other answer is that we hope to modify both
Intermetrics' compiler AdaMagic front-end, and the Gnat front-end to
handle this extension. With this kind of start, plus the blessing of
ODMG, we hope that the extension will become common in Ada compilers.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Other aspects of the binding are more similar to other language
bindings. A one-to-many relationship is represented by an attribute
for the to-one direction, and a collection object for the to-many
direction. Transactions and databases are represented as abstract
data types that correspond very closely to their C++ class
counterparts. The collection and iterator types are also very
similar."


-- John Howard <jhoward@sky.net> -- Team Ada Team OS/2 --
-- Free GNU-based Ada 95 compilers are at ftp://cs.nyu.edu/pub/gnat/ --
--

Return to the comp.compilers page.
Search the comp.compilers archives again.