[gclist] Finalization and death notices

Marc Shapiro -- at work marc.shapiro@acm.org
Sat, 6 Oct 2001 22:01:19 +0200


 || Date: Thu, 04 Oct 2001 14:57:45 -0500
 || From: Charles Fiterman <cef@geodesic.com>
 || Subject: Finalization and the insane postman bug.
 || 
 || what is required is a death notice. The user is informed
 || by some mechanism that an object died. The death notice is an identifer
 || associated with the objct not the object's address. Now priority, order,
 || time and context are in the user's control. If some objects are reference
 || counted they give death notices too.

I have been following this argument from afar.  Clearly there is a need
for some application-level cleanup mechanism when certain objects are
collected, but finalisers are very bug-prone.

I think I'm convinced now that finalisers are bad and death notices are
good.  A death notice is just an event posted by the system to the user
program.  It's up to the application code to pick it up at leisure.  So
it's the user's responsibility to fork threads or not, catch exceptions
or not, and to worry about termination or not.  The user gets the
service he needs, and the system does not get compromised.

 || Date: Thu, 04 Oct 2001 16:01:20 -0500
 || From: Charles Fiterman <cef@geodesic.com>
 || Subject: Re: Finalization, again
 || 
 || Finalizers must be safe, general, sure and ordered. [...]  Sure
 || means if you build a finalizer object the finalizer gets run if only
 || at end of job.

This was probably intended tongue-in-cheek but I'm not certain.
Promising that finalisers (or death notices) will eventually be
delivered for all objects is promising complete GC, which I don't
believe makes sense (and doesn't scale).