JEP 132: More-prompt finalization

[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 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
>>>>>