JEP 132: More-prompt finalization

[Vitaly Davidovich]

Curious - why do you say this? I don't want to diverge this thread but
that's a bold statement :).
On Jan 6, 2012 11:54 AM, "Kirk Pepperdine" <kirk at kodewerk.com> wrote:

> when it comes to performance, I'm not sure that the CLR is a good role
> model ;-)
>
> Regards,
> Kirk
>
> On 2012-01-06, at 5:32 PM, Vitaly Davidovich wrote:
>
> Tony,
>
> Interestingly the .NET CLR has an API  to allow apps to tell the
> runtime(gc specifically) to be more aggressive -
> System.GC.AddMemoryPressure/RemoveMemoryPressure.  The idea being that
> you'd call this when a managed object allocates native memory and thus adds
> overall pressure.  This hint is then used by the gc.  What are your
> thoughts on that? Granted this is more amenable for mem management and not
> other scarce resources.
> On Jan 6, 2012 11:17 AM, "Tony Printezis" <tony.printezis at oracle.com>
> wrote:
>
>> Kirk,
>>
>> Inline.
>>
>> On 01/06/2012 08:57 AM, Kirk Pepperdine wrote:
>>
>>> Tony, David,
>>>
>>> I really feel that this problem is being solved at the wrong level. The
>>> JVM lacks application semantics to know when to do the "right" thing.
>>>
>>
>> I absolutely agree.
>>
>>  So, IMHO,  this should be managed by the application.
>>>
>>
>> I absolutely disagree. :-)
>>
>> First, let's define some terminology to make sure we're all on the same
>> page:
>>
>> JVM : HotSpot
>> library : the Java code that manages certain native resource (e.g.,
>> classes in the java.io package) - I do not consider this part of the JVM
>> application : what the user writes which runs on top of HotSpot and uses
>> java.io.File's.
>>
>>  For the same reason, there are other things that the application
>>> shouldn't touch like telling the JVM it's time to run a collection.
>>>
>>
>> Amen to that. :-)
>>
>>  That said, one thing the JVM might know about is how many file
>>> descriptors it's allowed and it could trigger an attempt to recover them
>>> (i.e. run finalization) once they start running low..
>>>
>>
>> Indeed. But the JVM (as defined above) does not know anything about file
>> descriptors. It's the library, in this case classes in java.io, that
>> does. However, I don't think said library should also be calling
>> System.gc() either. It should be providing information to the GC, via the
>> API I have been suggesting, on how much of a certain resource we have and
>> the GC should be making informed decisions on whether it when it should
>> trigger a cycle.
>>
>> Tony
>>
>>   just as the JVM manages memory by recovering it when it runs low. That
>>> said, I did run a bench where we opened 1,000,000,000 sockets on a single
>>> VM. That is just about as many sockets as can be opened on a machine
>>> without recompiling the kernel to configure a bigger file descriptor
>>> bitmap. I'm quite happy that the JVM wasn't fighting me as I was trying to
>>> open all these sockets. While this bench was a bit extreme, it's clear that
>>> WebSocket gateways *will* stress file descriptor.
>>>
>>> Not sure about direct buffers though I do feel they should implement
>>> finalization as a fallback position.
>>>
>>> Cheers,
>>> Kirk
>>>
>>> On 2012-01-06, at 12:14 PM, David Holmes wrote:
>>>
>>>  Hi Tony,
>>>>
>>>> On 6/01/2012 8:34 PM, Tony Printezis wrote:
>>>>
>>>>> If each library could indicate to the GC whether the resource it
>>>>> manages
>>>>> is running low or not, using the API I mentioned, the GC could do the
>>>>> above automatically, behind the scenes, without the user having to do
>>>>> anything else.
>>>>>
>>>> I'm not sure a library writer has the necessary information to do this.
>>>> Seems to me that how an application uses a particular type determines the
>>>> scarcity of the resource. I can imagine something like:
>>>>
>>>> void setFinalizationLimit(Class<?>  cls, int limit)
>>>>
>>>> so that GC runs finalization once a "reference count" reaches "limit".
>>>> That limits the frequency of finalization, but the actual finalization cost
>>>> may still be unacceptably high.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>  Tony
>>>>>
>>>>>  Afterall the key thing about GC is it relieves the programmer from
>>>>>> having to manage object lifetimes, so if you don't know when the
>>>>>> object is no longer used you don't know when to call close.
>>>>>>
>>>>>> David
>>>>>>
>>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120106/7b55777e/attachment-0001.html