JEP 132: More-prompt finalization
Dmitry.Samersoff at oracle.com
Tue Dec 27 12:19:53 PST 2011
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.
Java Hotspot development team, SPB04
* There will come soft rains ...
More information about the hotspot-dev