JEP 132: More-prompt finalization

Dmitry Samersoff Dmitry.Samersoff at
Wed Dec 28 09:44:35 PST 2011

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

>> 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 Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...

More information about the hotspot-dev mailing list