From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | "Heiko W(dot) Rupp" <hwr(at)pilhuhn(dot)de> |
Cc: | Vitalii Tymchyshyn <vit(at)tym(dot)im>, PG-JDBC Mailing List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Remove usage of finalizers ? |
Date: | 2013-10-21 15:17:36 |
Message-ID: | 52654590.1050600@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On 21.10.2013 13:09, Heiko W. Rupp wrote:
> Am 21.10.2013 um 11:34 schrieb Vitalii Tymchyshyn:
>> 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.
If we can't get rid of the finalizer completely, I wonder if we could
arrange things so that we could avoid the finalizer overhead when there
are server-side resources associated with the statement. I would guess
that in most cases that you don't close a Statement properly, it's a
very short-lived Statement used to run a single query. Such a statement
will typically not have any server-side resources associated with it.
Actually, we already seem to use PhantomReferences to clean up orphaned
SimpleQuery and Portal objects. AFAICS those are the things that
actually represent server-side resources. Why do we even have a
finalizer in AbstractJdbc2Statement? Perhaps we used to rely on the
finalizer to clean up things, but later added the more fine-grained
PhantomReferences to the underlying objects, making the finalizer redundant?
> 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.
That's still negligible compared to sending a statement to the remote
host and getting the result back, though.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Dunstan | 2013-10-23 00:12:29 | Re: Remove usage of finalizers ? |
Previous Message | Dave Cramer | 2013-10-21 12:33:09 | Re: Remove usage of finalizers ? |