Re: Finalization and Garbage Collection: a hole in the RM?

[bobduff@world.std.com (Robert A Duff)]

In article <mazzanti-3008961532260001@mac-mazz.iei.pi.cnr.it>,
Franco Mazzanti <mazzanti@iei.pi.cnr.it> wrote:
>Are there any other holes like this one are hiding there?
>
>I am trying to write a roadmap to erroneous executions and other 
>unpredictabilities in Ada95, so for me it would be important to find all
>the possible issues of this kind.

Are you interested in erroneous/unpredictable stuff in general, or are
you interested specifically in issues related to garbage collection?

The index of the RM and AARM contains entries for "erroneous" and
"bounded error" that will let you track down all the cases.  Another
source of unpredictability is when the run-time semantics says
"arbitrary order".  I don't think that's in the index, but you could use
an editor to search the ascii version of the RM.

As for garbage collection, I don't know of any other major pitfalls
(other than interactions with finalization, I mean), and I already
posted the small amount of discussion in the AARM.  Another issue is
that you can point into the middle of objects (via renamings, and via
'Access on components).  So the last remaining pointer to an object
might actually point into the middle of it, or to a slice of it.  You
can point to non-existent stuff -- e.g. use 'Unchecked_Access to create
a pointer to a local variable, then return from the subprogram, leaving
the pointer pointing past the stack top.  This is not an error (assuming
the pointer is never referenced later), but the pointer is still there
for the gc to trip over.  A still-running task is not garbage, even if
there are no pointers to it, since it can reach out and do things.
Interactions between tasking and gc in general (e.g. you can't just run
the garbage collector when the user program is doing a "new", because
some other task might be doing something else).  Etc.  But these all
seem like solvable problems.

- Bob