JEP 132: More-prompt finalization

[Tony Printezis]

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