JEP 132: More-prompt finalization

[Bernd Eckenfels]

Hello,

Am Fri, 29 May 2015 12:18:06 +1000
schrieb David Holmes <david.holmes at oracle.com>:

> I guess I'm very concerned about the premise that finalization should 
> scale to millions of objects and be performed highly concurrently.

I would agree that it is a bad idea to design applications for such
demanding workloads and use finalizer and it is not a design goal for
the finalizer to support this.

> To
> me that's sending the wrong message about finalization. It also isn't
> the most effective use of cpu resources - most people would want to
> do useful work on most cpu's most of the time.

There is however a problem with the finalizer in sane applications:
even when you do not use any domain objects with finalize() you
still have to cope with JDK classes which needs it. This includes
file streams, java.util.zip, sockets (especially SSLSocket which
sends close records in a blocking manor (JDK-6932592)) and third party
libraries (unfortunatelly).

So if the finalizer queue builds up, it is often due to bad behaving
objects and the finalizer has not much to deal with it. This could be
as simple as diag commands, but it could also be a multi threaded
approach where no more than one class finalizer is executed at the same
time. I wish we had some (more) progress in this area.

Greetings
Bernd