JEP 132: More-prompt finalization

Jon Masamitsu jon.masamitsu at
Tue Dec 27 13:50:27 PST 2011


For applications that have large heaps which don't fill up
and so don't cause a GC (during which finalizable objects could be
discovered),  the least disruptive feature we've discussed is
to have a concurrent phase such as CMS's concurrent
marking phase discover finalizable objects.  As you note
this would eat up compute resources so it is something
we would make the application request.    For customers
for which this is not acceptable, this JEP will not
address their problem.


On 12/27/2011 12: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 wrote:
>>>>>> Posted:
>>>>> 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

More information about the hotspot-dev mailing list