[gclist] Allowing finalizers to wait for the messiah.

[Mark Tillotson]

> At 05:42 PM 5/22/97 +0100, you wrote:
> >> 1. You've still screwed up on
> >>    class foo {
> >>         ~foo() { foop = this; }
> >>         ...
> >>         ...
> >>    } *foop;
> >> 
> >I think the programmer's intend is clear there - any previous value of
> >foop gets collected next time.
> 
> But thats not what your algorithm does. It gets freed this time
> with foop still pointing at it. This is massivly unacceptable.

Please reread my algorithm, step 3 in particular.

> >> This can run forever for
> >>   class foo {
> >>         ~foo() { new foo }
> >>         ...
> >Of course it can, but I don't think that sort of code is ever useful?
> 
> Yes. Not this simple case, but destructors must be general that means they
> can create objects. So a foo creates a bar which creates a baz. Maybe the
> loop isn't infinite but its bad enough.
There isn't a loop here.

Firstly the new foo in your example has dynamic extent, and thus
wouldn't be registered for finalization anyway, and secondly even if
you create a chain of a hundred foo/bar/baz's with indefinite extent,
they could all be finalized _together_ on the next GC cycle if they
were all unreachable together.  My algorithm imposes no special
ordering on finalizable objects.  Its the simplest possible scheme
really.

__Mark
[ markt@harlequin.co.uk | http://www.harlequin.co.uk/ | +44(0)1954 785433 ]