finalize() method

[Victor Cheung]

Thanks, Peter.

We have some groovy code that gets compiled into java code.  The groovy code doesn't contain any implementation of the finalize method, and the class doesn't extend anything (i.e. superclass is Object).  So in my case it's really bad since the subclass is needlessly implementing finalize() that is trivial which calls the superclass empty finalize().  I do not know why the groovy compiler insists on producing the finalize() bytecode, i'll have to see if there's a work-around for this.  I found out by just searching our code base (including compiled classes and jars, etc.) for the "finalize" string.

I'm also going to run the Findbugs app and see if it can locate any other questionable code.

victor

________________________________________
From: hotspot-gc-use-bounces at openjdk.java.net [hotspot-gc-use-bounces at openjdk.java.net] On Behalf Of Peter B. Kessler [Peter.Kessler at Sun.COM]
Sent: Friday, December 19, 2008 9:05 PM
To: Victor Cheung
Cc: hotspot-gc-use at openjdk.java.net
Subject: Re: finalize() method

Victor Cheung wrote:
> void finalize() {
>   super.finalize();
> }
>
> is this bad?
>
> victor

In words of one syllable: yes.

If your superclass already has a non-trivial finalize() method, then it's not as bad as it would be if your superclass had only a trivial finalize() method.  (java.lang.Object.finalize() is a trivial finalize() method: it is the empty method.  Every class has java.lang.Object as superclass.)  If you are already inheriting a non-trivial finalize() method, we've already lost a lot of performance on object allocation, and slowed down recovering storage through two collection cycles, etc.  All you've added in that case is the overhead of dispatching from this subclass method to the superclass method, which is nothing compared to the overhead of running the finalize() method.  But, if you don't have anything to finalize() at this level of the inheritance hierarchy, then why would you add a finalize() method at this level?  If there's a non-trivial finalize() method somewhere in a superclass, it will be called when the object becomes unreachable: you don't have to help it along.

If your superclass didn't have a non-trivial finalize() method, then you've just added a whole lot of overhead: to object allocation, to collection, to storage recovery.  Don't do that if you don't have to.

If you do use finalize() methods, consider changing to use WeakReference subclasses and getting your notifications that way.  The web is full of good reasons to do that.

                        ... peter
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use