JEP 132: More-prompt finalization
Jon Masamitsu
jon.masamitsu at oracle.com
Fri Dec 23 08:50:35 PST 2011
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
>>>>
More information about the hotspot-dev
mailing list