Re: Remove usage of finalizers ?

Well, references:
1) Can be created only when needed (when there is something to dispose)
2) Can be cleared if close was called (most cases)
3) Processing can be skipped if connection is closed as a whole
4) Cleanup can be done during regular connection calls thus ensuring no
concurrent problems are added and clean-up requests don't pile up because
of CPU overload

References are much more superior to finalizers
23 жовт. 2013 21:05, користувач "Steven Schlansker" <
stevenschlansker(at)gmail(dot)com> написав:

>
> On Oct 23, 2013, at 10:58 AM, Adib Saikali <adib(dot)saikali(at)gmail(dot)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(at)gmail(dot)com>
> wrote:
> >
> >>
> >> On Oct 23, 2013, at 12:22 AM, John R Pierce <pierce(at)hogranch(dot)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(at)postgresql(dot)org)
> >> To make changes to your subscription:
> >> http://www.postgresql.org/mailpref/pgsql-jdbc
> >
> >
> >
> > --
> > 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
>
>
>
> --
> 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
>