Destructor nonsense on dlang.org

[Mehrdad]

On Friday, 25 May 2012 at 19:30:35 UTC, Jonathan M Davis wrote:
> On Friday, May 25, 2012 17:53:45 Mehrdad wrote:
>> @Andrei: The reason this is allowed is that finalization is
>> _separate_ from garbage collection in .NET. So an object can be
>> finalized and yet still not GC'd. Or its finalizer might be
>> suppressed, allowing it to get GC'd directly. This allows for
>> many possibilities, although you don't usually need them.
>
> Finalization _can_ be separate from the GC in D thanks to 
> clear, but it does
> normally occur as part of a collection cycle.
>
> - Jonathan M Davis

Uhm... sure...

I wasn't really talking about D, so I'm not sure what you mean.

But, comparing to D:

I'm _not_ talking about the fact that you can call the finalizer
manually.
That has _nothing_ to do with the "separation" I was referring to
(even though it's nevertheless necessary for separating the GC
from the finalization queue).

I'm talking about the fact that, if an object has a finalizer,
its finalization stage is SEPARATE from (and obviously, before)
the GC stage. In other words, there can be TWO passes over all
objects that are going to be GC'd:

1. Unreachable finalizable objects are finalized, and their
finalizers are suppressed.
2. Unreachable objects with no finalizers are GC'd.


Therefore, resurrection is possible because after an object goes
through stage 1, it may no longer be eligible for stage 2 (it may
have strong references).

Note that this means merely _having_ a finalizer causes an object
to take 2 passes to be GC'd, instead of 1 -- even if the
finalizer is empty.

Also notice that NOTHING is left in an undefined state, and yet
everything is guaranteed to be reclaimed at some point. And
circular references cause no problems whatsoever, because if
they're unreachable from the GC root, no one cares if they have
references to each other.


@Andrei: Does that make sense?