I haven't looked up references (yet) but my understanding is that Carl
is correct, if perhaps overly emphatic.  Based only on the API docs and
JLS, one can argue that instances of classes that do not override
finalize() can be collected without actually invoking Object.finalize(),
as the VM can know that its Object.finalize() is specified to do
nothing.  More importantly, however, it is possible for a finalize()
method to make the object it is invoked on reachable again (an odd state
indeed: finalized and reachable), so after finalizing an object with a
non-default finalizer, the GC must completely redo its reachability
analysis for that object.  Naturally, that also affects the reachability
of objects to which the one in question holds references.

The VM must also keep track of whether or not reachable objects have
been finalized, because they are only ever finalized once (per
specification).  That probably doesn't add much overhead, but it may
result in unexpected behavior when the second time an object becomes
unreachable it is discarded without its finalizer being invoked.

That would be an implementation question, but I suspect that many Java
GC implementations indeed do exactly as Carl describes.  It really is a
much bigger deal to collect an object with a non-default finalizer than
to collect other objects.

It might be a little too strong to say that Java's finalization
mechanism is broken, but I have never personally run into any task to
which it is suited.  It is definitely a trap, because people --
especially those with experience in some other OO languages, such as C++
-- tend to make incorrect assumptions about how finalization works.  It
has been said here before and it will be repeated again: a Java
finalizer is not at all the same thing as a C++ destructor.

John Bollinger
jobollin@indiana.edu

Observed behavior.  I just wrote up this test:

----------- Test2.java -----------
import java.util.*;
import java.lang.ref.*;

public class Test2
{
    public static void main(String [] args)
    {
        System.out.println(System.getProperty("java.version"));
        System.out.println(System.getProperty("java.vendor"));
        System.out.println();

        int [] sizes = {10, 100, 1000, 10000, 100000, 1000000};

        for (int i = 0; i < sizes.length; i++)
        {
            test(sizes[i]);
        }
    }

    private static void test(int size)
    {
        ReferenceQueue q = new ReferenceQueue();
        Set s = new HashSet();

        int count = 0;
        int nfcount = 0;
        int wfcount = 0;

        while (count < size)
        {
            s.add(new BooleanReference(new Object(), q, false));
            s.add(new BooleanReference(new WithFinalizer(), q, true));

            BooleanReference br;
            while ((br = (BooleanReference)q.poll()) != null)
            {
                s.remove(br);
                count++;
                if (br.flag)
                {
                    wfcount++;
                }
                else
                {
                    nfcount++;
                }
            }
        }

        System.out.println(count + " object collected.");
        System.out.println("Objects with finalizer collected: " + wfcount);
        System.out.println("Objects without finalizer collected: " +
nfcount);
        System.out.println();
    }

    private static class WithFinalizer
    {
        private static int whatever;

        protected void finalize()
        {
            whatever++;
        }
    }

    private static class BooleanReference extends PhantomReference
    {
        public boolean flag;

        public BooleanReference(Object referent, ReferenceQueue q,
boolean flag)
        {
            super(referent, q);
            this.flag = flag;
        }
    }
}
----------- end Test2.java -----------

I had a bit of an issue with an earlier version, as when I wasn't saving
BooleanReferences they were getting collected before the objects they
were referring to, which kind of made things more difficult.  :)

Anyway, here's the output of two different runs through it:

1.4.2_03
Sun Microsystems Inc.

242 object collected.
Objects with finalizer collected: 0
Objects without finalizer collected: 242

5723 object collected.
Objects with finalizer collected: 0
Objects without finalizer collected: 5723

5673 object collected.
Objects with finalizer collected: 0
Objects without finalizer collected: 5673

12115 object collected.
Objects with finalizer collected: 1957
Objects without finalizer collected: 10158

113516 object collected.
Objects with finalizer collected: 45157
Objects without finalizer collected: 68359

1093806 object collected.
Objects with finalizer collected: 487562
Objects without finalizer collected: 606244

-----------

1.5.0
Sun Microsystems Inc.

211 object collected.
Objects with finalizer collected: 0
Objects without finalizer collected: 211

1288 object collected.
Objects with finalizer collected: 0
Objects without finalizer collected: 1288

5707 object collected.
Objects with finalizer collected: 0
Objects without finalizer collected: 5707

20398 object collected.
Objects with finalizer collected: 5711
Objects without finalizer collected: 14687

111297 object collected.
Objects with finalizer collected: 46748
Objects without finalizer collected: 64549

1026543 object collected.
Objects with finalizer collected: 476431
Objects without finalizer collected: 550112

-----------

So, there's definately a bias against objects with finalizers in those
JVMs.  The bias becomes less extreme as more and more objects are
collected, but it's still present.

The extra work done by finalization may be useful, but there is no
added value if you could have done it yourself with a suitable
dispose() method. However the cost is there regardless.

Here's one:
 http://servlet.java.sun.com/javaone/javaone2000/event.jsp?eventId=1172

(In particular, pages (approx) 30-36 of the slides)

Although this was presented 4 years ago and some implementation
details have likely changed since then, several of the arguments he
presents against finalization (e.g. average age of objects and the
resulting effect on process size) certainly hold regardless of
implementation.

In particular, one aspect he mentions that seems to be missing from
this discussion, is the tree of objects that are artificially kept
alive because of references from (other) objects waiting for
finalization. Longer average object life leads to more live objects at
any given time, and consequently more work for the garbage collector.

If I've understood correctly, objects that use finalization must be
queued for gc a second time, after finalization has run.

Similar comments can be found in appendix A "The truth about garbage
collection, in "Java platform performace":
 http://java.sun.com/developer/Books/performance/

Here's another:
 http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html

/gordon