Re: Remove usage of finalizers ?

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@pilhuhn.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@pilhuhn.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@pilhuhn.de
> > Blog: http://pilhuhn.blogspot.com   @pilhuhn
> >
> >
> >
> > --
> > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-jdbc
>
> --
> Heiko Rupp   hwr@pilhuhn.de
> Blog: http://pilhuhn.blogspot.com   @pilhuhn
>

--
Heiko Rupp   hwr@pilhuhn.de
Blog: http://pilhuhn.blogspot.com   @pilhuhn



--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc