JEP 132: More-prompt finalization

[Kirk Pepperdine]

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/b26e0c83/attachment.html