Re: non-trivial finalize() on AbstractJdbc2Statement

From: Vitalii Tymchyshyn <tivv00(at)gmail(dot)com>
To: Imran <imranbohoran(at)gmail(dot)com>
Cc: Dave Cramer <pg(at)fastcrypt(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: non-trivial finalize() on AbstractJdbc2Statement
Date: 2012-02-15 12:50:42
Message-ID: 4F3BAA22.1040103@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

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

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Deiverson Silveira 2012-02-15 13:43:58 Problem for access schema in postgresl via JDBC
Previous Message Imran 2012-02-15 12:30:31 Re: non-trivial finalize() on AbstractJdbc2Statement