Re: Throwing Constructor Exceptions and cleaning up
Lew wrote:
Thomas Pornin wrote:
However, since finalizable
objects necessarily survive their first collection, it makes little
sense to allocate them in the young generation, since it would end up in
the old generation anyway.
Not necessarily. It takes more than one GC cycle for an object to
move from to the tenured generation.
This means that in that hypothetical GC implementation, you pay for half
of the extra cost associated with finalization when the instance is
created, even if finalization is suppressed afterwards.
As I pointed out in my previous post, suppression of finalization is
already in Java, so adding it would be redundant.
Lew, I think you've missed the thrust of the discussion. The
"suppression" considered here would require a way to tell the garbage
collector that an instance needs no finalization even though its
class implements a non-trivial finalize(). The use case is like
class Thing {
// ... lots of Java ...
private boolean disposed;
public void dispose() {
// clean up this Thing
disposed = true;
}
protected void finalize() throws Throwable {
try {
if (! disposed)
dispose(); // safety net
}
finally {
super.finalize();
}
}
}
The hoped-for optimization -- which, as far as I know, Java does
*not* support -- would be a way for the dispose() method to inform
the GC that it need not call finalize() for an already-dispose()d
Thing instance. To look at it another way, the optimization amounts
to moving `if (! disposed)' out of finalize() and into the GC,
which might be able to do it with less total overhead.
Whether such an optimization would be Good or Bad seems unclear.
For correctly-used objects it could simplify finalization to the point
of eliminating it. On the other hand, it might encourage people to
rely on finalize() in situations where they shouldn't; I can almost
hear the C++ converts saying "So *that's* how Java does destructors!"
--
Eric.Sosman@sun.com