Re: non-trivial finalize() on AbstractJdbc2Statement - Mailing list pgsql-jdbc
| From | Imran |
|---|---|
| Subject | Re: non-trivial finalize() on AbstractJdbc2Statement |
| Date | |
| Msg-id | CAG6o=AGcLBQZRo+A=F4m_Rk6D2PRHJvm1_=avCa283Q7kPHZEg@mail.gmail.com Whole thread Raw |
| In response to | Re: non-trivial finalize() on AbstractJdbc2Statement (Vitalii Tymchyshyn <tivv00@gmail.com>) |
| Responses |
Re: non-trivial finalize() on AbstractJdbc2Statement
|
| List | pgsql-jdbc |
So I've tried to run jstack over five times and it kept in saying it can't walk over the threads. We have a fair amount of background processes running, not sure if that made jstack fail. I've read that its possible to hit the error on jstack. My thread dumps from jvisualvm doesn't show the priority of any threads. Also the only thing the tread dumps have shown to me is that its waiting on RefernceQueue.remove, which holds the Finalizer objects that gets created due to finalize methods.
I did go through most of the finalizer objects in my heap dumps and all had referents as the jsbc3PreparedStatement. Also with my patched driver I've noticed every time I force a GC I see the old generation cleaning up nicely, which I didn't see when I had the driver with the finalize method.
Cheers
--Imran
15.02.12 14:30, Imran написав(ла):@Vitalli - w.r.t Thread priority, I've tried to get the priority off the jvm I'm running, but the thread dump nor jconsole/jvisualvm is giving this out to me. We run 1.6.0_12 on a 64bit linux platform. jvisualvm however shows that the Running percentage of the Finalizer thread is comparatively low. To my knowledge Finalizer thread is low by default, and looking at the Finalizer code, it does appear to be setting the priority to MAX_PRIORITY - 2.jstack shows you thread priorities.
Anyways that aside, heap dumps I've collected when we had OOMs have pointed at high Finalizer objects and the referent of those have been jdbc3Satement objects, which is why I raised this question. I'm not sure if its common practice to always use finalize() for any mop-up tasks, as I've seen other cautions raised around it, although I can see there are valid cases to do so.
For me:
Regular thread:
"Thread-69" daemon prio=10 tid=0x000000004683e800 nid=0x6834 waiting on condition [0x00007f80a7649000]
Finalizer:
"Finalizer" daemon prio=10 tid=0x00007f80c4001000 nid=0x6d35 in Object.wait() [0x00007f80c9747000]
So, priorities are equal.
Regarding heap sizes, that's what I am talking about! If someone holds Finalizer thread, especially in some blocking state (say synchronized) you will get OOM with a lot of objects that are created much, not ones that really holds the thread! That's why it's Running is low - someone it blocking on something in this thread. Otherwise if it has work, it would be in running state, no matter is OS've given it CPU time. Check it with jstack. You can do it even now, while you don't have OOMs you should still have the problem root - someone who is sitting in the finalizer doing it's work slow. You may even still have some leak, yet now while you have much less finalizable objects, the leak is much less visible. Note that you may not see it at single call if your cause does not take 100% of Finalizer thread time.
BTW: You can try to find the object being finalized from heap dump, check all objects visible from finalizer thread.
Best regards, Vitalii Tymchyshyn
pgsql-jdbc by date: