This content has been marked as final. Show 4 replies
[Reposted this issue|http://forums.sun.com/thread.jspa?threadID=5424655] in JVM Specification forum, which seems to be more actively.
Seems like any easy test would be to search the code base for finalize(). One could be the source of the problem.
Course if there a lot of them that would be a problem as well - regardless of whether it is the source of this problem.
Thank your very much for your answer!
Actually the application has a high object throughput rate and yes the libraries (JDBC, Toplink) and the application code itself do use finalize().
I'm even able to identify the queued finalizer through Yourkit by inspecting the referents of the finalizer ReferenceQueue.
But do i have the problem "too many finalizers" or do I have a differently situated issue (I'm distracted by the idling finalizer thread).
The use of finalize() requires the VM to track it specifically. There is no such requirement if finalize() is not being used.
So if many classes have finalize() or just few that have many instances created then it is certainly, in some way, going to require the VM to work more.
yes the libraries (JDBC, Toplink) and the application code itself do use finalize().Not sure what you mean by that but
- if you are using finalize() to manage jdbc then it is wrong
- if you are referring to finalize in jdbc drivers then it would certainly be unusual to have them cause a problem. I haven't see anyone else claim that. But if you are using a driver that isn't popular then that could be a problem.