Hello, Am Fri, 29 May 2015 12:18:06 +1000 schrieb David Holmes <david.hol...@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
