What makes Finalizers so costly?

Question

From Effective Java:

Oh, and one more thing: there is a severe performance penalty for using finalizers. On my machine, the time to create and destroy a simple object is about 5.6 ns. Adding a finalizer increases the time to 2,400 ns. In other words, it is about 430 times slower to create and destroy objects with finalizers.

What makes the Finalizers so costly ?

Commons

Wow, if you are cutting the nanosecond in half you probably shouldn't be using Java but consider a language that is closer to the metal :-) – Diamagnet

0.00000024 seconds isn't too much. If you're going to go through it like a million times then it might be 2 seconds. – Showery

BTW In a finalize() method you can make the object live again. e.g. by adding it to a collection. :P – Aby

Duplicate question... #2860621 – Rod

@alexy13 perhaps a million of these objects leads to a 2 second delay; however, if you do go through these objects frequently, then not using finalizers allow you to go through 430 of these objects. Without clear understanding of the Object's role, it is not a clear cut choice to "not worry about it". Perhaps they are transients in a rather large matrix calculation, in which case, 430 times faster would mean much larger matricies could be handled. Yes, you are generally right, but there are always exceptions. – Pungy

@Edwin I agree. It also depends on the machine that the finalizer was benchmarked on. Maybe today computers are so fast that's it's way smaller (not sure). I don't have much experience in the java programming language so I probably shouldn't make assumptions. – Showery

Answer 1

http://www.ibm.com/developerworks/java/library/j-jtp01274/index.html

extract from link above

Objects with finalizers (those that have a non-trivial finalize() method) have significant overhead compared to objects without finalizers, and should be used sparingly. Finalizeable objects are both slower to allocate and slower to collect. At allocation time, the JVM must register any finalizeable objects with the garbage collector, and (at least in the HotSpot JVM implementation) finalizeable objects must follow a slower allocation path than most other objects. Similarly, finalizeable objects are slower to collect, too. It takes at least two garbage collection cycles (in the best case) before a finalizeable object can be reclaimed, and the garbage collector has to do extra work to invoke the finalizer. The result is more time spent allocating and collecting objects and more pressure on the garbage collector, because the memory used by unreachable finalizeable objects is retained longer. Combine that with the fact that finalizers are not guaranteed to run in any predictable timeframe, or even at all, and you can see that there are relatively few situations for which finalization is the right tool to use.

Augie

Answer 2

The crucial difference is the very existence of a finalizer method, irrespective of what it does. As soon as the GC has finalizable objects, it must work much harder to get all the housekeeping right. It must mark them as finalizable, keep them in a pool, run finalization, check whether they're resurrected after that, juggle all kinds of multithreaded issues with finalizing code, and so on.

The difference can be seen most starkly in the GC's young generation: in an optimistic, and not entirely rare scenario, the GC'ing boils down to a single operation: decrementing the pointer to the first available memory address. With finalizers, it's the whole process outlined above.

Challenging

You probably need to rephrase "The crucial difference is the very existence of a finalizer method," as "The crucial difference is the very existence of a non trivial finalizer method," since every object has a finalize() method . – Commons

Actually, if I delete the word "method", I'll be in line with the JLS. However, I left it there because it seemed more obvious that way. – Challenging

Answer 3

When you benchmark, you probably benchmark the useful life of the Object.

Objects exist beyond their useful life, basically there is a time delay between having the last program reference disappear and the garbage collection routines (which run in a different thread) detect the detached Object. When you add a finalizer, your "useful life" of the Object now extends until after garbage collection detects the detached object, and after the JVM runs the finalization method.

It isn't 100% because a finalization method exists that finalization adds so much time, a lot of that time is waiting for the garbage collection threads to wake up and eventually stumble upon your detached object (and decide to do something about it).

Pungy