Re: Remove usage of finalizers ?

On Oct 23, 2013, at 10:58 AM, Adib Saikali <adib.saikali@gmail.com> wrote:

> Seems to me that PhantomReferences can solve this problem as they will provide the ability to the cleanup without causing the performance issues with the finalizers. I am not familiar with the postgres jdbc driver code base so I have no idea how much work is involved in switching from finalizers to phantom references.
>
> Can anyone with knowledge of the jdbc code base comment on the practicality of moving from finalizers to phantom reference.
>

Do we in fact know that phantom (or weak?) references are cheaper than Finalizers?

It may be that switching to References makes turning a "debug mode" on or off much easier (i.e. no need to subclass) but it would be nice to have some evidence as to whether it will be faster or not, and under what workloads.

> On 2013-10-23, at 1:47 PM, Steven Schlansker <stevenschlansker@gmail.com> wrote:
>
>>
>> On Oct 23, 2013, at 12:22 AM, John R Pierce <pierce@hogranch.com> wrote:
>>
>>> On 10/23/2013 12:06 AM, Vitalii Tymchyshyn wrote:
>>>> I am not big fan of finalizes. But you propose to remove mechanism that works most times, without introducing anything else.
>>>> You are saying that as in my incorrect application (and I am 95% sure you've got incorrect application if you are getting finalizing objects piled up) it does not work, let's remove it altogether and make driver also wrong.
>>>
>>> as an outsider to this stuff, with only a superficial understanding of these finalizers, it seems to me they should log a warning if anything leaks to them.  you don't get rid of them entirely, they provide backup sweeping up of neglected debris..
>>>
>>
>> The specific problem with this is that the mere presence of a non-empty finalizer increases the cost of object allocation and deallocation by orders of magnitude (as is claimed by many Java performance resources).  All correct applications pretty much have to deallocate these objects explicitly, as the GC can leave the resources lying around for unbounded time.  So having these finalizers penalizes the correct applications (which I have not observed in practice, but OP seemingly has) by some amount.
>>
>>
>> Maybe the best thing would be for the OP to distill the problem down into a self-contained code example so we can verify that there aren't any other errors that might be contributing to this problem?  It seems that if the problem was really that big, someone else would have run across it.
>>
>> Best,
>> Steven
>>
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc



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