Re: Doing one last thing to a WeakReference

Lew wrote:
Joshua Bloch, /Effective Java/
<http://java.sun.com/docs/books/effective/index.html>,
Item 7, "Avoid finalizers".

Tom Anderson wrote:
And Lew, this is especially for you:

http://weblogs.java.net/blog/tball/archive/2005/08/finally_a_good.html

The evils of finalizers, AND error logging!

That article suggests heavy use of finalizers, which according to
everything I've read would cause slowdowns in the application.
Whether those slowdowns are significant is another question. I think
I'll stick with Mr. Bloch's advice and only use 'finalize()'
sparingly.

Lew:
They are not guaranteed to run at all.

Tom:
Isn't the only situation where they won't run at all if the program exits?

Not in principle, no. If there isn't enough pressure on memory to
force a collection after the Java object is dereferenced, then
'finalize()' will not happen.

OK, yes, because then by definition the program will exit without
running 'finalize()'.

Even if it does eventually run, it may have been delayed long enough
to put pressure on other resources. For example, if 'finalize()'
releases a resource connection, it may take so long to get around to
'finalize()' that the program runs out of available connections.

If 'finalize()' does get called in time to release the resource, it
still can cause trouble. Because it takes at least two GC cycles to
release a finalizable object, it puts extra pressure on memory.

Things are further complicated by the scenario proposed by the OP,
where additional objects are referenced from the logic. Doing that
from 'finalize()' can cause weirdness.

Lew:
When one must use finalizers there are ways to minimize the impact, for
example to use a helper class that has a non-trivial 'finalize()' that
another class composes, and to release the reference to the finalizable
member before releasing the containing instance.

Tom:
I'm not sure i [sic] quite understand. Is this for situations where there are
other objects hanging off the outer class, so you don't get them sucked
into finalization limbo?

Yes. Not the 'outer' class, but the finalizable one.

If a finalizable object holds a lot of references, their GC is
delayed, too.

This is all out there in the literature. That's where I got the
information, and maybe I don't remember it as well as I should. GIYF.

--
Lew
.

Relevant Pages

  • Re: I have seen some fat client Dot Net apps
    ... An object holding an unmanaged resource will be collected soon after it goes out of scope. ... Finalizers run in the context of the GC thread which means that this thread has to be synchronized. ... they add significant load to a GC sweep and this GC sweep will even freeze all other threads. ... When a class did not implement a finalizer to free a non-collectable resource, then you are screwed and introduced a real mem-leak. ...
    (borland.public.delphi.non-technical)
  • Re: Continuations in Common Lisp (with apologies)
    ... > You're asking for reliable finalization. ... as soon as the code using the resource finishes, ... The programmer should explicitly specify the intent. ... This fails to notice that reliable asynchronous finalizers must be run ...
    (comp.lang.lisp)
  • Re: Throwing Constructor Exceptions and cleaning up
    ... Java/, or Goetz does in a DeveloperWorks article, or both - my recollection on that is dim. ... Google if interested. ... is the resource I believe you are referring to, although Bloch also references it in /Effective Java/ ... finalizers are finicky and are not a reliable substitute for C++ destructors. ...
    (comp.lang.java.programmer)
  • Re: Why dont people like lisp?
    ... "Rainer Deyke" writes: ... > Joe Marshall wrote: ... > last reference to the file is gone. ... Common Lisp as currently formulated does not have finalizers, ...
    (comp.lang.python)
  • Re: Why dont people like lisp?
    ... "Rainer Deyke" writes: ... > Joe Marshall wrote: ... > last reference to the file is gone. ... Common Lisp as currently formulated does not have finalizers, ...
    (comp.lang.lisp)