JEP 132: More-prompt finalization

Ulf Zibis Ulf.Zibis at
Fri Dec 23 14:43:43 PST 2011



Am 23.12.2011 21:33, schrieb Charles K Pepperdine:
> 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>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>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 wrote:
>>>>>>> Posted:**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

More information about the hotspot-dev mailing list