JEP 132: More-prompt finalization

[Kirk Pepperdine]

Hi Dmitry,

I just received and email from one of my customers. I've cut and paste on of the paragraphs.

> We have already put our expanded knowledge to good use, Daniel was doing
> some debugging on an old application, performance was sub par. He checked
> the gc log which showed that the application was doing full gc a lot. He
> searched the code and found 118 System.gc(); calls! :-D Daniel received
> guru status for removing the calls and performance was noticeable quicker!

Tony dropped a nice diagnostic into the GC logs and it's a bullet point in my GC log seminars.

There is something that I've not investigated so I might start by asking.. why does RMI call System.gc()?

Regards,
Kirk

On 2011-12-28, at 8:18 AM, Dmitry Samersoff wrote:

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