On Wed, Nov 6, 2013 at 10:49 AM, Domenic Denicola <
domenic at domenicdenicola.com> wrote:

> Over lunch I was discussing ES6 and ES7 features with some developers
> doing JavaScript crypto, and they mentioned an interest in not only weak
> references, but weak callbacks. That is, a notification when your object
> gets garbage collected, similar (I think) to what V8 has with its
> `MakeWeak`, and what C# has with its finalizers.
>
> Such a feature would be non-deterministic, since it depends on when the
> garbage collector runs; the callback may never run at all. But it could be
> useful for performing cleanup tasks related to a given weak reference. I
> imagine it could even be emulated with polling plus weak references, so
> there should be nothing fundamentally new here.
>
> Personally I would find this feature somewhere between useful and an
> attractive nuisance. It would have to be carefully advertised as for
> last-ditch cleanup, not a substitute for deterministic disposal (via e.g. a
> `dispose()` method). C# has a similar dichotomy, with `IDisposable` for
> deterministic disposal, and a conventional pattern where you call
> `dispose()` in your finalizer if the consumer forgot to do so themselves.
>
> What do people think of this feature?
>

In a garbage collected language, this is known as pre-mortem finalization,
as in Java's finalize method and finalizer queue, and it is an unmitigated
disaster. It is like shared state multi-threading in that it creates a
category of bugs -- in this case, resurrection bugs -- that you totally
underestimate until you get bitten by them over and over, in code you
thought you had carefully thought through.

The problem is that, upon invoking the finalize method of the condemned
object, the object is *no longer* garbage because it is running. Since
non-garbage is reachable from garbage, the condemned object can make state
changes to non-condemned state, including storing a pointer back to itself **or
other co-condemned objects**, "resurrecting" them in that they are now
non-garbage.

Post-mortem finalization by various Smalltalk folks was a major innovation.
Its central insight is that computation never touches condemned state, and
so you never need worry about the possibility of resurrection. I have found
that anything useful that could be expressed with pre-mortem finalization
can be expressed, usually better, with post-mortem finalization by a bit of
refactoring.




> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131106/0610ea63/attachment.html>

In a garbage collected language, this is known as pre-mortem finalization,
as in Java's finalize method and finalizer queue, and it is an unmitigated
disaster. It is like shared state multi-threading in that it creates a
category of bugs -- in this case, resurrection bugs -- that you totally
underestimate until you get bitten by them over and over, in code you
thought you had carefully thought through.

The problem is that, upon invoking the finalize method of the condemned
object, the object is *no longer* garbage because it is running. Since
non-garbage is reachable from garbage, the condemned object can make state
changes to non-condemned state, including storing a pointer back to itself **or
other co-condemned objects**, "resurrecting" them in that they are now
non-garbage.

Post-mortem finalization by various Smalltalk folks was a major innovation.
Its central insight is that computation never touches condemned state, and
so you never need worry about the possibility of resurrection. I have found
that anything useful that could be expressed with pre-mortem finalization
can be expressed, usually better, with post-mortem finalization by a bit of
refactoring.