JEP 132: More-prompt finalization
kirk at kodewerk.com
Tue Dec 27 15:16:33 PST 2011
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?
On 2011-12-27, at 9:19 PM, Dmitry Samersoff wrote:
> 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 .
>> On 12/24/2011 4:33 AM, Dmitry Samersoff wrote:
>>> 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?
>>> On 2011-12-23 20:13, Jon Masamitsu wrote:
>>>> 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)
>>>> 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
>>>> 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.
> Dmitry Samersoff
> Java Hotspot development team, SPB04
> * There will come soft rains ...
More information about the hotspot-dev