JEP 132: More-prompt finalization

[Tony Printezis]

Does AddMemoryPressure() take any parameters? Creating a new socket (out 
of a max of say 1,000,000) should have different weight to, say, 
creating a new file (out of a of say 50).

Tony

On 01/06/2012 11:32 AM, 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 
> <mailto: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 <http://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 <http://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/5111f34c/attachment-0001.html