Re: Remove usage of finalizers ?

Well the current code is even worse as I found that we weren't even calling
super() inside the finalize which I understand is not a good thing.

Please send patches for possible solutions. I think I would be OK with
removing them and letting people find their Statement leaks

Dave Cramer

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

On Mon, Oct 21, 2013 at 6:09 AM, Heiko W. Rupp <hwr(at)pilhuhn(dot)de> wrote:

>
> Am 21.10.2013 um 11:34 schrieb Vitalii Tymchyshyn:
>
> > Are you sure that you have priority problem? I'd say it's possible but
> not too probable. Have you checked your finalizer stack traces?
>
> Did you read the article? This clearly shows that under load those
> problems can arise even with very trivial finalizers.
> The problem is normally not visible under light load, as here the creation
> of new Statements etc. is not that fast and the
> app itself has idle phases so that the finalizer daemon gets time to run.
> Under higher load you have more work on the application threads and are
> creating much more objects.
> This also means that the garbage collector needs more time to run and thus
> the finalizer thread gets less.
> As objects are not finalized, the garbage collector has even more work to
> do, which reduces the available time
> for the finalizer even more.
>
> > Note that removing finalizers without introducing some other mechanism,
> like reference queues, would introduce server side leaks on poorly written
> yet correct applications!
>
> Server side leaks are introduced the moment that you rely on a finalizer
> being called (close to the time the object is no longer needed).
> Per JLS, the finalizers are a) not guaranteed to ever run, b) run in any
> specific order c) at any given time.
>
> And the other mechanisms exist -- close() calls. Software that relies on
> the finalizer for this cleanup may show unpredictable
> behavior.
>
> Another reason to get rid of finalize() methods is that Object creation is
> several hundred times slower with the finalize()
> methods present, as not only the Statement etc. is created, but also the
> Finalizer and the later needs to be put on the finalizer
> queue. Josh Bloch talks about 5.6ns vs 2400ns for a simple object in
> "Effective Java, 2nd edition".
> That is a penalty everyone has to pay - even if they close Statements etc
> correctly.
>
> Heiko
>
>
> >
> > 21 жовт. 2013 11:06, користувач "Heiko W. Rupp" <hwr(at)pilhuhn(dot)de>
> написав:
> >
> > Am 21.10.2013 um 08:29 schrieb Vitalii Tymchyshyn:
> >
> > > Long finalized queue means that some of your objects finalizes long.
> This means that either you don't close some of your statements explicitly
> or you have different type
> >
> > Actually this is a false assumption. The finalizer daemon thread has a
> low priority and can sometimes
> > not keep up with the most trivial cases. See e.g.
> http://www.fasterj.com/articles/finalizer1.shtml
> >
> > And yes, closing statements and other objects (e.g. LOBs) explicitly
> makes a lot of sense.
> >
> >
> > > of objects (even if it's small number) that take long time to
> finalize. Check stack trace of finalized thread.
> > > As of driver, removing finalize altogether is not good as statements
> won't be closing implicitly. Possible options are:
> > > 1) Move processing out of finalizer thread with reference queues.
> > > 2) Warn when something is implicitly closed to indicate usage problem.
> >
> > That is what I meant: have 2 drivers:
> >
> > - one for devlopment that does the warning in the finalizer and the
> closing, but very loud warning
> > - one for production where the finalize() methods are gone.
> >
> > Again: there is no guarantee that a finalize() method is ever called
> from the JVM. So relying on
> > it may create bogus results
> >
> > >
> > > 20 жовт. 2013 23:33, користувач "Heiko W. Rupp" <hwr(at)pilhuhn(dot)de>
> написав:
> > > Hey,
> > >
> > > the other day we ran into a situation where our app ran into a OOME
> situation on heavy
> > > load. It turned out that we had around 290k objects on the Finalizer
> queue, that
> > > were Statements.
> > >
> > > There has been a discussion in the past about finalizers (
> > > see e.g. around
> http://www.postgresql.org/message-id/BCD42993-CB7B-453F-95B4-09E84A956AB0@me.com)
> > >
> > > I understand that Connection objects are supposed implement a
> finalizer (is that actually true?),
> > > but here the penalty is not that high, as Connections usually are
> pooled and are thus long living.
> > >
> > > Other JDBC objects like Statements are extremely short lived and the
> creation rate can be
> > > on a busy application much higher than the finalization rate (which is
> what we were seeing).
> > >
> > > So I wonder if the driver could be rewritten in a way that either
> > > - uses no finalizers for the short lived objects
> > > or
> > > - exist in 2 flavors: a debug version that does excessive logging in
> the
> > > finalizer if the objects were not yet closed (and stays as is wrt the
> extra work)
> > > and a production version where
> > > the finalize() methods are removed, so that the objects do not end up
> > > in the finalizer queue and can't pile up under high load.
> > >
> > > Developers could then use the devel version and the other driver for
> production.
> > >
> > > Relying on the finalize() method to close/free objects on the PG
> server is a bad
> > > idea anyway, as there is no guarantee when finalizers run or if they
> run at all.
> > >
> > > Thanks
> > > Heiko
> > >
> > >
> > > --
> > > Heiko Rupp hwr(at)pilhuhn(dot)de
> > > Blog: http://pilhuhn.blogspot.com @pilhuhn
> > >
> > >
> > >
> > > --
> > > Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> > > To make changes to your subscription:
> > > http://www.postgresql.org/mailpref/pgsql-jdbc
> >
> > --
> > Heiko Rupp hwr(at)pilhuhn(dot)de
> > Blog: http://pilhuhn.blogspot.com @pilhuhn
> >
>
> --
> Heiko Rupp hwr(at)pilhuhn(dot)de
> Blog: http://pilhuhn.blogspot.com @pilhuhn
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>