A recent failure of the AWT Reliability test appeared to be
caused by allocation outpacing the Garbage Collector.
Peter Kessler expressed the opinion that it was likely to be
the Finalizer that was being overwhelmed (see below for
his email on the subject). He also explained why finalization
is such a drain on resources, inhibits scalability, etc., and
expressed the opinion that finalizers could often be replaced
by more efficient methods:

> There are lots of good ideas floating around about how to get
> the "clean up" aspects of finalization without its drawbacks.
> Mostly they involve moving to weak or phantom references, or
> reducing what's accessible from any remaining final references.
> Maybe we should make up a "best practices" document based on
> examples we fix from the AWT/Swing code.
>
> ... peter

We should investigate the possibility of removing or decreasing
our dependence on finalizers in the Tiger time frame, or earlier.
Toward that end, I have filed bugs against AWT, Drag&Drop, 2D,
Swing, and Input Methods as placeholders.

- Eric


--------- Begin email from Peter Kessler -------------------------

Remember, every object with a finalize method has to be discovered
to be otherwise unreachable once to put it on the finalizer queue,
then its finalize() method has to be run, then it has to be
discovered to be unreachable again before the storage for it
can be reused.

If your application uses 100% of the CPU cycles available,
the finalizer thread may fall behind. If the finalizer thread
falls behind, objects remain in the heap for too long, and the
heap expands to accomodate them (up to your maximum heap size),
but full collections slow down because the heap is bigger and
the collector has to look at more objects. (See my JavaOne
demo for details.)

If the problem goes away when you add small amounts of idle time
to your application, then the finalizer queue is probably the
problem, as the "idle" time is used to run the finalizer thread.

(We need better debugging hooks to let users see the length (and
volume) of the finalizer queue. The finalizer queue is in the
libraries, not the VM. From the VM I could find the finalizer
queue and run down it to find its length, but that's always seemed
like the wrong hammer to use. Adding a counter to Finalizer.java
seems like a better one.) For internal use, the Serviceability
Agent may be your friend.

[Eric Hawkes]
> My question is: is this a bug? If so, what should be
> done about it?

The JLS doesn't promise that finalize() methods will be run
promptly. It does promise that they will be run before the
storage is reused. On the other hand, if the storage can't
be reused because the finalize() methods haven't been run,
then the collector can't reuse the space and you will run out
out of memory. People have suggested that when we run out of
memory we run the finalize() methods in preference to other
code, but if the finalize() methods need more memory they
won't run if we are out of memory.

It's also easy to back up the finalizer queue by having finalize()
methods that do a lot of work. If finalize() is more expensive
than allocation then a program that "just" does allocation
will back up the finalizer queue. Since allocation is parallelized
but finalization isn't (or need not be), running on a multi-processor
requires that you rethink the relative cost of allocation versus
finalization.

--------- End email from Peter Kessler -------------------------

- Eric (###@###.###)