On 15/03/2017 8:21 PM, Timo Kinnunen wrote:
Hi,
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?/
ExitThread applies to the current thread, which means it would terminate
the finalization thread.
The java.lang.Thread object can not be GC'd before the native thread has
terminated from the VMs perspective (which is earlier than when the
thread terminates from the OS perspective). Once it has terminated the
finalizer may run and do whatever it does - it has no affect on the
native thread from the VMs perspective.
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.
For a thread to claim ownership of a resource such that the thread would
be responsible for "finalizing" that resource, you would have to
implement a reliable means to ensure the resource can only be
transferred amongst threads and never actually shared. But yes this
would be another form of thread-centric resource management if a means
were provided to register such resources with the thread and to clean
them up as part of thread termination. Of course you can implement a
simple/crude form of this directly in a custom thread class.
David
-----
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
*From: *David Holmes <mailto:david.hol...@oracle.com>
*Sent: *Wednesday, March 15, 2017 00:57
*To: *Timo Kinnunen <mailto:timo.kinnu...@gmail.com>; Andrew Haley
<mailto:a...@redhat.com>; Hans Boehm <mailto:hbo...@google.com>; Uwe
Schindler <mailto:uschind...@apache.org>
*Cc: *core-libs-dev <mailto:core-libs-dev@openjdk.java.net>
*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.
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.
