JEP 132: More-prompt finalization

[Kirk Pepperdine]

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. So, IMHO,  this should be managed by the application. 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.

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.. 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