RFR 9: 8165641 : Deprecate Object.finalize

Timo Kinnunen timo.kinnunen at gmail.com
Wed Mar 15 10:21:46 UTC 2017


If we are to come up with a good alternative to finalization, having to compare disparate things seems unavoidable. Comparing threads and Threads, suppose there’s a subclass of Thread which holds a native resource that’s not reachable from any other Thread and it has a finalize method. Let’s say this Thread’s resource is a handle to its own native thread and the finalize method calls CloseHandle on the handle and ExitThread to signal an A-OK exit code. The thread will not be removed from the system while the handle remains open. Could this Thread’s thread invoke its own finalize method once it’s done or would it have to wait for the Finalizer to call it instead, and if so, why?

Being able to say “this resource will be finalized by the Thread from which it was last reachable” would be quite useful for this case and augment the current finalization without having to replace it.

Sent from Mail for Windows 10

From: David Holmes
Sent: Wednesday, March 15, 2017 00:57
To: Timo Kinnunen; Andrew Haley; Hans Boehm; Uwe Schindler
Cc: core-libs-dev
Subject: Re: RFR 9: 8165641 : Deprecate Object.finalize

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.


> 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.

More information about the core-libs-dev mailing list