Re: non-trivial finalize() on AbstractJdbc2Statement

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
On Feb 15, 2012 12:50 PM, "Vitalii Tymchyshyn" <tivv00(at)gmail(dot)com> wrote:

> 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.
>> 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.
>>
> jstack shows you thread priorities.
> 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
>
>