JEP 132: More-prompt finalization

[Jon Masamitsu]

David and Ramki,

I stand corrected.  1) and 2) in my reply are library changes.
I'll modify the JEP and throw it over the fence :-)  I guess I was
thinking "what can we do before we have to think about an API".

Ramki, that this JEP has been published doesn't mean that
anyone is executing on the changes.  If I understand the rules
correctly, it just says "Here's an idea, anyone want to talk
about it?"   The state of the JEP is "posted".  I think it changes
to something else if it is actually worked on.   I'm not working
on it.

Jon

On 12/23/2011 8:24 AM, Srinivas Ramakrishna 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
>>>