JEP 132: More-prompt finalization

[Srinivas Ramakrishna]

As Jon stated, the API may not be necessary if the other enhancements pan
out and provide
enough improvement in the cases being looked at. There was some discussion
of
a "nudge the VM" variety, and you are right that such API's can be abused.
For the
kind of API that "nudge the VM to finalize/process Reference objects"
probably entails,
one would likely put in some defensive front-end boiler-plate to protect
against
abuse, especially when composing from multiple 3rd party libraries each of
which
may evolve to use its own "local" policy for nudging. The other thing that
protects
against abuse is when one finds that it hurts to carelessly (ab)use the API
(witness the (ab)use of System.gc() in early versions of Java applications).

-- ramki

On Fri, Dec 23, 2011 at 12:33 PM, Charles K Pepperdine <kirk at kodewerk.com>wrote:

> Hi all,
>
> I don't want to sound elitist about this but I would suggest caution when
> thinking about exposing Java level API to "control" finalization. It is my
> experience when talking about finalization that it is rare that developers
> (and I do talk to 100s of developers every year) have any idea about how
> finalization works. It is rare to find a developer that knows about the
> finalization thread let alone that there's a helper thread and other
> reference types to support the process. I'm happy that finalization is
> there and it works as intended and that the details are buried so I don't
> really have to think about them.
>
> Regards,
> Kirk
>
> On Dec 23, 2011, at 5:50 PM, Jon Masamitsu wrote:
>
> > Ramki,
> >
> > No you were right with your original thinking.
> >
> > Jon
> >
> > On 12/23/2011 8:27 AM, Srinivas Ramakrishna wrote:
> >> i.e. unless I minsunderstood "more aggressive management of the
> >> finalization queue"
> >> as something the JVM does based on its understanding of the dynamic
> >> demographics
> >> of FinalRefs or something like that.
> >>
> >> -- ramki
> >>
> >> On Fri, Dec 23, 2011 at 8:24 AM, Srinivas Ramakrishna<ysr1729 at gmail.com
> >wrote:
> >>
> >>> Hi Jon,
> >>>
> >>> That is true. However, those modifications are in the core libraries.
> The
> >>> VM<->JDK library interaction ceases,
> >>> in some sense, at the GC<->RefHandler boundary. So I tend to agree with
> >>> David that
> >>> the immediately-affected APIs and their implementation (also mentioned
> by
> >>> you above)
> >>> are in the core libraries. It makes sense to include the core-libs
> alias
> >>> into the discussion.
> >>>
> >>> The JEP also mentions modifications to he RefHandler thread (and,
> between
> >>> the lines, perhaps
> >>> has the GC<->RefHandler interaction in mind?). One question: are the
> >>> changes envisaged for
> >>> the RefHandler thread going to affect the promptness of handling other
> >>> Reference subtypes
> >>> than just FinalReferences?
> >>>
> >>> PS: I am glad this JEP is being executed; Finalizers are not going to
> go
> >>> away anytime soon,
> >>> even though many applications have been rewritten to reduce their
> reliance
> >>> on promptness
> >>> o Finalization. Thus, this will help many many Java users out there.
> +1!
> >>>
> >>> thanks.
> >>> -- ramki
> >>>
> >>>
> >>> On Fri, Dec 23, 2011 at 8:13 AM, Jon Masamitsu<
> jon.masamitsu at oracle.com>wrote:
> >>>
> >>>> David,
> >>>>
> >>>> From the VM side there are two issues that I think we should
> understand
> >>>> better before we work on an API.  Those are described in the JEP as
> >>>> 1) more aggressive management of the of finalization queue and 2)
> multiple
> >>>> finalizer threads.  We should see how much of the problem can be
> >>>> alleviated by either or both or by other VM side changes that occur
> to us
> >>>> during the work and then think about what is left and what information
> >>>> we want from the user to address what's left.   As Mark has said, I
> >>>> think there will be a library side JEP at some point for those
> >>>> discussions.
> >>>>
> >>>> Jon
> >>>>
> >>>>
> >>>> On 12/22/2011 6:15 PM, David Holmes wrote:
> >>>>
> >>>>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote:
> >>>>>
> >>>>>> Posted: http://openjdk.java.net/jeps/**132<
> http://openjdk.java.net/jeps/132>
> >>>>>>
> >>>>> hotspot-dev seems the wrong mailing list to discuss this. It is
> >>>>> primarily a Java level API. I would suggest using core-libs-dev.
> >>>>>
> >>>>> David
> >>>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111223/b5fcfd53/attachment.html