Re: non-trivial finalize() on AbstractJdbc2Statement - Mailing list pgsql-jdbc
| From | Imran |
|---|---|
| Subject | Re: non-trivial finalize() on AbstractJdbc2Statement |
| Date | |
| Msg-id | CAG6o=AELXcR5XHt3s=1NLx3sRDnhRjtSj2yWFbL7O+KR2Qo2FQ@mail.gmail.com Whole thread Raw |
| In response to | Re: non-trivial finalize() on AbstractJdbc2Statement (Dave Cramer <pg@fastcrypt.com>) |
| Responses |
Re: non-trivial finalize() on AbstractJdbc2Statement
(Vitalii Tymchyshyn <tivv00@gmail.com>)
|
| List | pgsql-jdbc |
@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.
@Dave - I have done this and as mentioned in the previous post, I haven't run into the OOM issues under similar load.
Cheers
-- Imran
On Wed, Feb 15, 2012 at 11:42 AM, Dave Cramer <pg@fastcrypt.com> wrote:
Just for kicks why don't you remove the finalize method recompile theOn Wed, Feb 15, 2012 at 6:30 AM, Vitalii Tymchyshyn <tivv00@gmail.com> wrote:
> Hello.
>
> The finalizer thread is not a low priority thread in my JVM (openjdk) and as
> soon as Statement.close does nothing (and it does nothing if statement is
> closed), I don't see how can it be a problem to free memory. Actually
> statement creation is much more heavy thing than "if (flag) return". It's
> perfectly valid to close native resource (and as far as I know statement
> allocates server-side native resources) in finalizer. Another implementation
> can be to create a ReferenceQueue and a bunch of References that should be
> checked now and then during connection calls, but this introduces additional
> processing that is not needed most time. You can't drop this code altogether
> as while it's good practice to close statements in client code, you can't
> guarantee it's done everywhere. Actually it's common practice in java to
> clean-up external resources in finalize, see for example FileOutputStream.
> As of your problem, I don't thing statement finalize method is the problem
> cause. I can see two causes:
> 1) The code bug mentioned in this thread
> 2) Some another class with long finalize method. This is the case that can
> lead to confusion. Say, you have an object created once in 5 minutes that
> has 3 minutes finalize. It won't hurt by itself as it's enough time to be
> finalized. But as soon as you have additional object with finalized method
> defined (say, Statement), even empty, all this objects can't be freed during
> this 3 minutes run and you will get OOM. And you will rarely blame your
> custom object. The best check that can be done to show real reason is to
> check Finalizer object stack with jstack. I did often see cases when custom
> finalize method is fast, but is synchronized by some heavy-used resource.
>
> Best regards, Vitalii Tymchyshyn
JDBC jar and try it.
pgsql-jdbc by date: