[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-dev
Subject:    JEP 132: More-prompt finalization
From:       Dmitry.Samersoff () oracle ! com (Dmitry Samersoff)
Date:       2011-12-28 17:44:35
Message-ID: 4EFB5583.5000005 () oracle ! com
[Download RAW message or body]

On 2011-12-28 13:55, Kirk Pepperdine wrote:
> > But there are plenty of usecases when we can't determine the moment when we can \
> > explicitly close socket.
> 
> I'm not saying that these use cases don't exist but I'm not recalling running into \
> one of them.. ever. And I if I asked this question in a more general forum my guess \
> is that it would be unanimous in that no one else has run into them.  I'm wondering \
> if there is a one-off solution for the "use-cases" that
you've happen to run into (aside from the connection pooling etc?).
> would certainly not want to give people more rope to hang themselves
with all for the sake of a problem that most likely is rooted in the
design of the application. Just say'in

It's not a simple question - when you should close socket ever without Java.
e.g.   An app read data stream and stop receiving data at some point.
You can close socket immediately to benefit server or wait to benefit
client.


> > Each of them has it's own workaround (e.g. connection pool manager with \
> > refcounting or separate checker thread)
> I'm not sure that I'd call these work-arounds as they all serve a multitude of \
> purposes.. but, beyond the scope

Nowdays we have plenty of memory so we can delay socket (an other
resources) reclamation but save some CPU power. It's especially valuable
if an application have clear visible pick and spare hours.


> but I would like to see finalizers as recommended solution for these cases. 
> and this is inherently tied to GC? So, if we consider Jon's solution, I still would \
> not want a API call to trigger it.  If you look at enough GC logs (which btw, I \
> collect as a hobby ;)) 

For about 6 years in sustaining I looked at GC logs enough times, but
decided to collect hs_err_.logs - it requires less space ;-)).

 I agree with you - there is no reason to have an API to trigger GC or
finalization explicitly. I dream about a time when JVM would be able to
detect low load time and start GC/finalization automatically.
  But today there are a cu's cases that can't be solved without
such API.

> Happy New Year,

Happy New Year ;)
-Dmitry

-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...


[prev in list] [next in list] [prev in thread] [next in thread]