[gclist] Finalization and death notices

[Greg Colvin]

From: Boehm, Hans <hans_boehm@hp.com>
> > From: Greg Colvin [mailto:gcolvin@us.oracle.com]
> > 
> > From: Boehm, Hans <hans_boehm@hp.com>
> > > I think that some of what we're really talking about here 
> > is the choice
> > > between three alternatives:
> > > 
> > > 1) The collector directly runs finalizers from whichever 
> > thread happened to
> > > allocate and invoke the collector.  This is common in early Java
> > > implementations, but fundamentally broken.  It leads to intermittent
> > > deadlocks and/or multiple threads in the same monitor.  
> > Let's ignore this
> > > alternative.  (Such a facility can sometimes be used to implement a
> > > reasonable one.  But if it's there it shouldn't be exposed 
> > to the user.)
> > 
> > Is this approach broken if it is done immediately after the last
> > pointer to an object goes away, as with reference counting?
> > 
> Yes.  See http://www.hpl.hp.com/personal/Hans_Boehm/gc/det_destr.html .
> 
> It breaks whenever the finalizer needs to acquire a lock that may be held
> during a pointer assignment.  (Or when it should logically hold such a
> lock.)  That's likely to happen whenever a finalizer updates a global
> user-level data structure.  

OK.  So this is why Limbo doesn't provide destructors except
for kernel objects?