RFR 9: 8165641 : Deprecate Object.finalize

[David Holmes]

On 16/03/2017 3:06 PM, Timo Kinnunen wrote:
> Hi,
>
> Yes, indeed it does. I find it intriguing that finalization as currently
> specified is so unsuited for managing the one native resource that from
> a Java programmers point-of-view the JVM is managing perfectly. This
> resource being of course not memory, but thread handles.

I'm afraid you've lost me. Threads have a very clear and well-defined 
lifecycle and so are trivially managed. Finalization was never intended 
to manage threads as they don't need managing.

David
-----

>
>
> I think by using a cleanup thread pinned to the same processor as the
> thread about to exit it would be possible to make it seem like the
> thread was cleaning up after it has exited, but this point isn’t really
> important.
>
>
>
> I now realize that “this resource will be finalized by the Thread from
> which it was last reachable” is too strong for what I had in mind. I
> should have said something more along the lines of “this resource will
> be finalized before the Thread from which it was last reachable or other
> Threads after it fail to acquire a new one”. The operative words
> “before” and “after” and no mention of synchronization making it a
> per-processor core rather than a per-thread function.
>
>
>
> As for what comes after, I’d like to propose that any proposed
> alternative to finalization be evaluated for both improvements in
> functionality and ease of use of its interface. Specifically, compared
> to finalization the alternative should show the same level of improved
> functionality as GC in Java 8 shows compared to GC of Java 1.0.
> Similarly, its ease of use should not be significantly worse than what
> the ease of use of GC in Java 8 is compared to what using GC in Java 1.0
> was. This sets a high bar, perhaps, but as Java 8 demonstrates it’s a
> bar that’s attainable.
>
>
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *David Holmes <mailto:david.holmes at oracle.com>
> *Sent: *Wednesday, March 15, 2017 11:38
> *To: *Timo Kinnunen <mailto:timo.kinnunen at gmail.com>; Andrew Haley
> <mailto:aph at redhat.com>; Hans Boehm <mailto:hboehm at google.com>; Uwe
> Schindler <mailto:uschindler at apache.org>
> *Cc: *core-libs-dev <mailto:core-libs-dev at openjdk.java.net>
> *Subject: *Re: RFR 9: 8165641 : Deprecate Object.finalize
>
>
>
> 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.holmes at oracle.com>
>
>> *Sent: *Wednesday, March 15, 2017 00:57
>
>> *To: *Timo Kinnunen <mailto:timo.kinnunen at gmail.com>; Andrew Haley
>
>> <mailto:aph at redhat.com>; Hans Boehm <mailto:hboehm at google.com>; Uwe
>
>> Schindler <mailto:uschindler at apache.org>
>
>> *Cc: *core-libs-dev <mailto:core-libs-dev at 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.
>
>>
>
>>>
>
>>
>
>>
>
>>
>
>
>