Skip site navigation (1) Skip section navigation (2)

Re: non-trivial finalize() on AbstractJdbc2Statement

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Vitalii Tymchyshyn <tivv00(at)gmail(dot)com>
Cc: Imran <imranbohoran(at)gmail(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 11:42:21
Message-ID: CADK3HHLy4V5U3qd-HrkFjPe-V5p_MHih2RajHOqDVVA_yW_SGg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
On Wed, Feb 15, 2012 at 6:30 AM, Vitalii Tymchyshyn <tivv00(at)gmail(dot)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


Just for kicks why don't you remove the finalize method recompile the
JDBC jar and try it.


Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

In response to

Responses

pgsql-jdbc by date

Next:From: ImranDate: 2012-02-15 12:30:31
Subject: Re: non-trivial finalize() on AbstractJdbc2Statement
Previous:From: Vitalii TymchyshynDate: 2012-02-15 11:30:15
Subject: Re: non-trivial finalize() on AbstractJdbc2Statement

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group