JEP 132: More-prompt finalization

[Ulf Zibis]

+1

-Ulf


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