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
causingthe performance issues with the finalizers. I am not familiar with the postgres jdbc driver code base so I have
noidea 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)
butit 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
anythingelse. 
>>>> You are saying that as in my incorrect application (and I am 95% sure you've got incorrect application if you are
gettingfinalizing 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
loga warning if anything leaks to them.  you don't get rid of them entirely, they provide backup sweeping up of
neglecteddebris.. 
>>>
>>
>> The specific problem with this is that the mere presence of a non-empty finalizer increases the cost of object
allocationand deallocation by orders of magnitude (as is claimed by many Java performance resources).  All correct
applicationspretty much have to deallocate these objects explicitly, as the GC can leave the resources lying around for
unboundedtime.  So having these finalizers penalizes the correct applications (which I have not observed in practice,
butOP 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
verifythat there aren't any other errors that might be contributing to this problem?  It seems that if the problem was
reallythat 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