Hi, The design decision to manage native threads on behalf of the Java programmer was made a long time ago. One consequence of that decision is that today there is no alternative threading library for Java that would allow me to terminate a thread that’s gone into an infinite loop, to give an example.
Looking into the future where Object.finalize has been deprecated and then removed from the JVM after an orderly migration period to its replacement, it’s worth considering what facilities would this future JVM provide that would make managing the resources used by your own implementation of threads as trivial as it should be. And who on earth could want to implement their own threading? Project Sumatra might. Sent from Mail for Windows 10 From: David Holmes Sent: Thursday, March 16, 2017 06:41 To: Timo Kinnunen; Andrew Haley; Hans Boehm; Uwe Schindler Cc: core-libs-dev Subject: Re: RFR 9: 8165641 : Deprecate Object.finalize 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.hol...@oracle.com> > *Sent: *Wednesday, March 15, 2017 11:38 > *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 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. > >> > >>> > >> > >> > >> > > >
