JEP 132: More-prompt finalization

[Kirk Pepperdine]

Hi Dmitry,

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?

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