Re: More finalize woes

[Tom Tromey]

Stephen> However, I can envisage wanting to use Classpath / Jikes /
Stephen> gcj in experimental JVMs where Object.finalize needs to do
Stephen> something.

Seems like an experimental VM like that would have to do its work
under the hood, given that Object.finalize is documented as doing
nothing.

Stephen> [* Calling "super.finalize" in a finalizer for a direct
Stephen> subclass of Object insulates the programmer from problems if
Stephen> he/she changes the inheritance structure.  Note: the
Stephen> programmer may be using a different Java compiler by then
Stephen> ... ]

Yeah, I think it makes some sense from a maintenance/refactoring point
of view.  This doesn't affect Classpath, though, since the hierarchy
won't be changing (one presumes).

Stephen> 2) treating direct subclass of Object as a special case makes
Stephen> the compiler complicated

I'm not swayed by this; the cost of this really doesn't seem
important.  Plus this is the sort of thing it is trivial to write a
regression test for.

However, adding a warning like this is probably not warranted.
Ideally a Java programmer would treat the standard library as a kind
of black box, and always call super.finalize().  However, not all
classes inherit from the standard library; the programmer might know
that this call is unnecessary and want to omit (for style reasons if
nothing else).

Per> If (to allow changing class hierarchies as above) you require all
Per> classes to contain:
Per>    public void finalize () { super.finalize(); }

You only need to call super.finalize() if you are already adding a
finalizer.  Otherwise you can just inherit the superclass finalize.

I think Object.finalize is a corner case.

Such a call should be very cheap: super calls are always inlineable (I
assume most JITs would inline, and thus eliminate, this call), and
even if not, the cost of the call will be dwarfed by the cost of
finalizing in the first place.  (FWIW right now I don't think gcj will
inline this.)

Still, there doesn't seem to be much point in requiring it.
We already know it won't do anything.

Stephen> If project policy strictly prohibits warnings, it must wear
Stephen> the cost of code to circumvent the warnings.  In this case,
Stephen> the cost will be vanishingly small, at least in realistic
Stephen> examples.

Per> Yes, but only if the JVM does the recommended optimization.
Per> I don't know if GCJ does.

I lost track of which optimization you mean.  gcj won't register a
finalizer for a method that inherits Object.finalize (in fact we have
a special allocation path for the no-finalizer case).  It will for all
other finalizers (trivial or not).  We could recognize trivial
finalizers without much trouble; a long time ago I had a patch to do
it.  There didn't seem to be much point in it though.

Tom