Finalization 
Author Message
 Finalization

Will Dylan have a facility for notifying an object that it is about to
be garbage collected? To me this seems to be an especially important
feature for creating reliable software. If I create an object that
holds on to some operating system resource, how can I ensure that the
resource will be freed when the object goes away?

Dylan seems to have the m{*filter*}equivalent to C++ constructors with its
initialize method, but I haven't heard of any mention of an equivalent
to destructors.

// Patrick C. Beard
// Computing Research Group



Mon, 17 Mar 1997 05:21:00 GMT  
 Finalization


: >Will Dylan have a facility for notifying an object that it is about to
: >be garbage collected?

: It is unlikely that finalization will be added in the current design round,
: since the current effort is on cleaning up loose ends and writing the book.
: I suspect that most Dylan implementation will at least have weak pointers,
: which allows you to perodically poll for objects having died.  

: There is no obvious unproblematic formulation of GC'd heap finalization.  The
: biggest semantic difficulty is the "resurrection problem": if the finalization
: method is run on the object after the object becomes garbage but before it is
: collected, then the finalization method can add new references which cause the
: object to no longer be garbage.

: If resurrection is allowed, this can complicate GC, and also opens the
: possibility that an object can be finalized more than once.  If resurrection
: is not allowed, then there is potential for dangling object references.

How about this scheme....I proposed it in the eiffel newsgroup but
it seemingly didn't generate much interest.

All objects that need to be finalized are registered somewhere with
a special pool of references to these objects---call it "limbo".

Now, the references to objects in "limbo" still count as live pointers
to the collector, and therefore these objects, and any objects to
which they refer, will still stay live and valid.

When the *only* reference to some given object comes from this limbo
pool---meaning that the rest of the program has effectively forgotten
about it---the finalization procedure is run on this limbo object.

When this finalization procedure is running, the object is still alive
and perfectly valid, so there's no problem there.  After finalization
is over, the reference to it is removed from limbo and so it now
becomes real garbage, having already been finalized.

This scheme sounds too simple that somebody hasn't thought of it before.

comments?

:   Rob MacLachlan

--

-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".



Wed, 19 Mar 1997 06:16:47 GMT  
 Finalization

Quote:

>When this finalization procedure is running, the object is still alive
>and perfectly valid, so there's no problem there.  After finalization
>is over, the reference to it is removed from limbo and so it now
>becomes real garbage, having already been finalized.

This sounds like a reasonable solution.  In the terms of the previous post,
by default an object will be finalized only once.  If the object is
resurrected, the application must re-register it for finalization if it is
intended that it be finalized again the next time it's about to be GCed.

I think the resurrection issue is only a problem if finalization is
automatically implemented for all objects of some classes.  So long as it's
done using some form of explicit registration, there shouldn't be a
problem.
--

Barry Margolin
BBN Internet Services Corp.



Thu, 20 Mar 1997 06:06:15 GMT  
 Finalization

   I think the resurrection issue is only a problem if finalization is
   automatically implemented for all objects of some classes.  So long as it's
   done using some form of explicit registration, there shouldn't be a
   problem.

I don't see why "automatically for all objects of some class" and
"explicit registration" are at odds, since the obvious implementation
would be for initialization method to do the registration.




Sat, 22 Mar 1997 03:50:19 GMT  
 Finalization

Quote:

> I think the resurrection issue is only a problem if finalization is
> automatically implemented for all objects of some classes.  So long as it's
> done using some form of explicit registration, there shouldn't be a
> problem.

This is unfortunate, as I'd hoped to be able to use finalization as a
general purpose technique to ensure that resources that are no longer
being used can be released in a sensible way.

Why wouldn't it be feasible to have a class that automatically registers
its instances with the finalization mechanism in its initialize method?
This could then be used as a mix-in class for developers of classes that
have to deal with OS resources, such as windows or non garbage collected
handles.

Resurrection seems to have dubious utility to me. Why support it? (I hope
I don't get misquoted...)

// Patrick C. Beard
// Computing Research Group



Sat, 22 Mar 1997 10:59:19 GMT  
 Finalization

Quote:

>I don't see why "automatically for all objects of some class" and
>"explicit registration" are at odds, since the obvious implementation
>would be for initialization method to do the registration.

They aren't at odds.  My point was that the system is incomplete if it
*only* has "automatic for all objects of some classes" finalization, since
it lacks the necessary control of multiple finalization.

If the system has explicit registration, and some classes automatically
register themselves, that's fine.  That doesn't preclude re-registering
them if they're resurrected, if that's desired.
--

Barry Margolin
BBN Internet Services Corp.



Sat, 22 Mar 1997 12:14:41 GMT  
 Finalization

Quote:
>This is unfortunate, as I'd hoped to be able to use finalization as a
>general purpose technique to ensure that resources that are no longer
>being used can be released in a sensible way.

You can do that, so long as you arrange to re-register if necessary.

Quote:
>Resurrection seems to have dubious utility to me. Why support it?

How do you prevent it?  If the finalization routine for an object contains

(setq *global-var* object-being-finalized)

then the object will no longer be garbage -- it will have been
resurrected.  I suppose you could specify that applications shouldn't do
this, but it's difficult for them to know whether any of the functions they
call cache their parameters (Common Lisp's DYNAMIC-EXTENT declaration has a
similar problem, and we didn't address this issue either).
--

Barry Margolin
BBN Internet Services Corp.



Sat, 22 Mar 1997 15:44:14 GMT  
 Finalization

Quote:


>: If resurrection is allowed, this can complicate GC, and also opens the
>: possibility that an object can be finalized more than once.  If resurrection
>: is not allowed, then there is potential for dangling object references.

>How about this scheme....I proposed it in the eiffel newsgroup but
>it seemingly didn't generate much interest.

>All objects that need to be finalized are registered somewhere with
>a special pool of references to these objects---call it "limbo".

>Now, the references to objects in "limbo" still count as live pointers
>to the collector, and therefore these objects, and any objects to
>which they refer, will still stay live and valid.

>When the *only* reference to some given object comes from this limbo
>pool---meaning that the rest of the program has effectively forgotten
>about it---the finalization procedure is run on this limbo object.

>When this finalization procedure is running, the object is still alive
>and perfectly valid, so there's no problem there.  After finalization
>is over, the reference to it is removed from limbo and so it now
>becomes real garbage, having already been finalized.

Or, if the finalization function stores a reference to the object in
another live structure, the finalized object is now an "ordinary" live
object (no resurrection problems) without doing anything extra at all.

Quote:
>This scheme sounds too simple that somebody hasn't thought of it before.

Yes, we have implemented a finalization mechanism (in Chez Scheme)
that detects when an object should be finalized in essentially the
same manner as you describe (we call it a protected list, not limbo)
and have written it up in our paper "Guardians in a generation-based
collector", in the 1993 SIGPLAN PLDI conference.  One important
difference is that a finalization procedure is not executed
immediately for the object; rather, the collector puts objects to be
finalized on a queue that the application program can check explicitly
so that the application can decide when finalization actually occurs.
If finalization occurs at any point in a program when a collection can
occur, an application has to disable collections whenever resources
(e.g. mutable objects) shared by the application and finalization
procedures are manipulated (you essentially have a classic concurrent
update problem because the finalization code could be run at any point
in the application where a collection could be triggered,
e.g. function calls or allocation operations). Having a finalization
method associated with an object that is called at collection time
when the object is determined to be inaccessible is another example of
this very same problem.

A Guardian is a dynamically created object that encapsulates a
finalization queue in a procedure. Calling a guardian with an object
registers the object for finalization and calling the guardian with no
arguments returns the next object from the queue associated with the
guardian that needs to be finalized (or #f if there are none). Objects
can be registered with more than one guardian or more than one time
with the same guardian, or one guardian can even be registered with
another guardian without any problems. The only real tradeoff is that
if the application does not hang onto a pointer to the object after it
is returned by a guardian (the usual case in many applications), the
dead object is not reclaimed until after the next collection.  This
delay in reclaiming inaccessible objects appears to be the inherent
price of avoiding the problem with dangling references when the
finalization procedure is allowed access to the object. The paper
describes the collection algorithm, how to make it generation
friendly, and how guardians interact with weak pointers.

Carl



Sun, 23 Mar 1997 02:13:47 GMT  
 Finalization

Quote:

> Resurrection seems to have dubious utility to me. Why support it?
> (I hope I don't get misquoted...)

I hope you don't get quoted out of context!   :-)

Edward



Wed, 07 May 1997 05:30:32 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Finalization

2. Triggering Finalization?

3. Confused by finalization in VW

4. Finalization

5. DLL&C connect and finalization (VM crash)

6. VW 3: WeakArray finalization question

7. Understanding finalization

8. Stung by finalization framework again

9. DLL&C connect and finalization (VM crash)

10. Finalization?

11. Finalization?

12. Problem with ISE Eiffel3 finalization

 

 
Powered by phpBB® Forum Software