[gclist] Guardians

[Carl Bruggeman]

--------
> On Apr 10,  8:30pm, Carl Bruggeman wrote:
> > Subject: Re: [gclist] Guardians
> > --------
> > This may indeed be a significant part of the problem.  In our system,
> > a pointer chain of guardian protected objects (even a circular chain)
> > that becomes inaccessible will have all of its protected objects
> > placed on their respective guardian queues during the same collection.
> Right.  I don't consider that desirable.  But it's also basically what Java
> does.  I don't think it's a disaster, but it's suboptimal.

This is one area where we can agree to disagree.  As we argue in our
paper, we believe that it is _critical_ that an entire chain or cycle
be placed on their respective guardians in the same collection. 
Otherwise, it takes a chain of N dependent objects N collections to be
finalized.  From some of the earlier messages that I skimmed over, I
think this problem has been described on this list as the
"Billion-dollar lottery payed over a billion years" problem.

Also, in what way can this be considered suboptimal?  

> > Ah, another part of the problem.  Guardians do not provide
> > "finalization".  They provide some useful information from the
> > collector, which can among other things be used to implement
> > finalization.  When an object is placed on a guardian queue (or
> > queues) during a collection, the collector is informing the program
> > that that the object registered with the guardian became inaccessible,
> > except via a guardian pointer(s), during the collection.  After all
> > guardian protected objects are placed on their respective queues, all
> > of the objects reachable from these objects are traced and copied.
> > Thus guarded objects and all objects reachable from them are "normal"
> > after being placed on a guardian queue and guardians can implement any
> > type of service, not just finalization; there are no restrictions on
> > what can be done with objects retrieved from a guardian; the object
> > becomes inaccessible (and its storage is reclaimed) only when there is
> > no strong pointer or guardian pointer to the object.

> I think we're splitting hairs here.  The Cedar finalization mechanism also

I suppose this is another area where we can agree to disagree.  Our
mechanism is completely general (but can be used for finalization)
while yours is tightly bound to finalization.  We consider this
generality to be an important feature of our mechanism.  Since we are
the only ones to have implemented guardians that I know of, it would
be premature to argue that this type of generality is not useful;
time will tell.

> pointers.  But I strongly suspect that the most common use for finalization i
n
> exisiting systems is to explicitly return resources allocated from third-part
y
> libraries (which are typically written in C or C++).  This involves a call to

I will agree that your solution for your current problem domain
appears to be a reasonable solution (and I will even grant you that
your problem domain is currently the most important application area,
in terms of economics, for finalization).  I just do not want to see
the _concept_ of finalization constrained to what is common, reasonable,
and practical in C++.

> "deallocate" procedure in the third-party library.  Typically this call will
> explicitly deallocate memory (and possibly do other things).  Thus subsequent
> calls into the library involving the deallocated resource are likely to resul
t
> in dangling pointers.  This is the kind of dangling pointer problem you
> encounter with non-topological-order finalization.

Yes.  You can encounter these types of "dangerous" problems with
guardians as well as with topological finalization if a programmer
uses weak-for-finalization pointers (clearing pointers) incorrectly.

> > > The default behavior should be to err on the side of safety.  In the
> presence
> > > of topologically ordered finalization, you (on rare occasions) do need a
> > > mechanism that corresponds to explicitly clearing pointers.  That allows
> you
> > to
> > > use other orderings when you have to.  (In the version implemented in our
> >
> > I believe that this confirms that topological ordering is not always
> > the correct order.  You explicitly clear pointers to change the order
> > of finalization (requiring global knowledge of the dependencies on the
> > part of the programmer to do so), while we advocate using multiple
> > guardian queues to handle finalization dependencies.
> The right ordering is the topological ordering minus some of the dependencies