JEP 132: More-prompt finalization

[Dmitry Samersoff]

Kirk,

On 2011-12-28 03:16, Kirk Pepperdine wrote:
> I'm not sure that this usecase is a bug
> in GC/finalization but a misunderstanding of what
 > finalization does and how it's suppose to function.
> If they know the socket is dead, why not just call close on it?

If I know that socket is dead I don't need finalization at all, so
it runs out of scope of this thread.

But there are plenty of usecases when we can't determine the moment when 
we can explicitly close socket. Each of them has it's own workaround 
(e.g. connection pool manager with refcounting or separate checker 
thread) but I would like to see finalizers as recommended solution for 
these cases.

-Dmitry

> Regards,
> Kirk
>
> On 2011-12-27, at 9:19 PM, Dmitry Samersoff wrote:
>
>> Jon,
>>
>> It's not a real (escalated) case. Just an accumulation of
>> what I heard from cu during last five years.
>>
>> On 2011-12-27 20:49, Jon Masamitsu wrote:
>>
>>> Before I try to answer your question, do you ever try to use
>>> System.gc() to get finalizers to run?
>>
>> Nope. Because (as you write it below) it's too disruptive especially
>> because I have to call System.gc() twice to dry finalization queue.
>>
>>>   If you don't because
>>> System.gc() it too disruptive (generally being stop-the-world),
>>> are you using CMS and have you tried using System.gc()
>>> with -XX:+ExplicitGCInvokesConcurrent?
>>
>> Nope also. In most cases System.gc(CMS) cause valuable performance
>> degradation for cu's app.
>>
>>
>> To clarify cu requirements:
>>
>> e.g Huge trader like CBOE.  It has the application that have to be very
>> responsive during a stock work day.
>>    So they tune VM to have no GC during work day. Then they kill the app
>> and start everything again next morning.
>>
>> The problem is -  they rely to finalization to do some task. Most
>> important (but not the only one) one is socket reclaiming .
>>
>> -Dmitry
>>
>>
>>
>>
>>>
>>> Jon
>>>
>>> On 12/24/2011 4:33 AM, Dmitry Samersoff wrote:
>>>> Jon,
>>>>
>>>> One of problem with finalization nowdays is that with 1 Tb heap GC (and
>>>> thus finalization) never happens.
>>>>
>>>> Do you plan to address this problem?
>>>>
>>>> -Dmitry
>>>>
>>>>
>>>> On 2011-12-23 20:13, Jon Masamitsu 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
>>>>>> 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
>>>>
>>
>>
>> --
>> Dmitry Samersoff
>> Java Hotspot development team, SPB04
>> * There will come soft rains ...
>


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...