On 15/03/2017 12:01 AM, Timo Kinnunen wrote:
Hi,

File handles aren’t that scarce of a resource, really, at least on Windows. On 
Windows threads are a lot scarcer resource than file handles, and I don’t 
recall anyone suggesting Java’s GC wasn’t suitable for managing that limited 
but crucially important resource. The question should then be, what makes 
threads so much easier to manage than file handles and how can we make file 
handles be more like threads?

Native thread resources are directly tied to the lifetime of the thread. Once it reaches the end of execution then all native resources with it are reclaimed. It's lifecycle is very specific and well-defined and not related directly to any other entity in the system. Comparing threads to GC managed objects, or file handles, is trying to compare completely disparate things.

David
-----

Food for thought: threads need a big stack which means a lot of memory, but a 
file handle might be just 8 bytes which is hard to keep track of. So, change 
the storage of file handles to use slot-0 of new long[65536];






Sent from Mail for Windows 10

From: Andrew Haley
Sent: Tuesday, March 14, 2017 11:14
To: Hans Boehm; Uwe Schindler
Cc: core-libs-dev
Subject: Re: RFR 9: 8165641 : Deprecate Object.finalize

On 12/03/17 23:55, Hans Boehm wrote:

But I think we agree that it doesn't matter for this discussion;
neither of these problems are addressed by deprecating
finalizers. PhantomReferences have exactly the same issues. And in
my experience it's unfortunately unrealistic to say we're going to
use neither. There will be Java wrappers for native objects. And
they will be embedded in Java data structures.  Requiring explicit
management for those amounts to mostly throwing out Java garbage
collection.

Not exactly: Java garbage collection is great for what it was intended
to do, i.e. managing memory.  It's terrible for managing other scarce
resources such as file handles.  There are much better ways to do
that: explicit resource acquisition, good old-fashioned reference
counting, etc.

Andrew.

Reply via email to