JEP 132: More-prompt finalization

[Kirk Pepperdine]

Hi Dmitry,


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

I'm not saying that these use cases don't exist but I'm not recalling running into one of them.. ever. And I if I asked this question in a more general forum my guess is that it would be unanimous in that no one else has run into them. I'm wondering if there is a one-off solution for the "use-cases" that you've happen to run into (aside from the connection pooling etc…).  would certainly not want to give people more rope to hang themselves with all for the sake of a problem that most likely is rooted in the design of the application. Just say'in

> Each of them has it's own workaround (e.g. connection pool manager with refcounting or separate checker thread)

I'm not sure that I'd call these work-arounds as they all serve a multitude of purposes.. but, beyond the scope

> but I would like to see finalizers as recommended solution for these cases.

and this is inherently tied to GC… So, if we consider Jon's solution, I still would not want a API call to trigger it. If you look at enough GC logs (which btw, I collect as a hobby ;)) you can see that these concurrent phases can be quite disruptive.  And, as if the case with a full GC, when should you call it? I certainly have neither the context nor the information needed to make that decision which is why I rely on the built-in heuristics to make that decision for me. In my course notes on finalization I mention that GC never runs is one of the 3 cases where you cannot rely on finalization working for you.

So, I'm going to bow out 'cos at the end of the day, I'm just a lowly observer who is now a trouble maker where as you're actually doing something useful.

Happy New Year,
Kirk

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