Re: RFR: 8277861: Terminally deprecate Thread.stop
On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman wrote: > Thread.stop is inherently unsafe and has been deprecated since Java 1.2 > (1998). It's time to terminally deprecate this method so it can be degraded > and removed in the future. > > This PR does not propose any changes to the JVM TI StopThread function (or > the corresponding JDWP command or JDI method). Endorsed. - PR: https://git.openjdk.java.net/jdk/pull/6616
Re: RFR: 8277861: Terminally deprecate Thread.stop
>> It is almost impossible to write any non-trivial code that is >> async-exception-safe and no JDK library code is written to be >> async-exception-safe including thread tear-down. So while you can say >> "stop() is the only way to disrupt this piece of code", you cannot ensure >> that it is disrupted safely. Once stop is used you need to throw away _all_ >> stateful objects that may have been in active use while ThreadDeath was >> propagated. And even during propagation you can easily trigger secondary >> exceptions. It seems that it should be possible to stop a thread spawned to execute code in a native library that works on data in native memory.. If what you say about thread tear-down is true, then I guess I would need to spawn the thread from native code as well. > On Nov 30, 2021, at 5:58 PM, David Holmes wrote: > > On 1/12/2021 3:13 am, Alan Snyder wrote: >> Although I understand the potential dangers of using Thread.stop, it seems >> to me there are cases where its use is legitimate and valuable. > > No there really aren't. :) The perceived utility of stop() is an illusion. It > is almost impossible to write any non-trivial code that is > async-exception-safe and no JDK library code is written to be > async-exception-safe including thread tear-down. So while you can say "stop() > is the only way to disrupt this piece of code", you cannot ensure that it is > disrupted safely. Once stop is used you need to throw away _all_ stateful > objects that may have been in active use while ThreadDeath was propagated. > And even during propagation you can easily trigger secondary exceptions. > > Cheers, > David > > >> The examples I am thinking of involve a potentially long running computation >> whose result is no longer needed. >> In particular, I am thinking of pure computations such as image analysis or >> audio analysis that do not involve waiting (so that interrupt is not useful) >> and probably are implemented using some C library (which is not feasible to >> modify to insert code to support graceful interruption). >> Is there some alternative that can be used in such cases? >> Perhaps a version of stop() that only works if no locks are held? >> Alan >>> On Nov 30, 2021, at 7:51 AM, Roger Riggs wrote: >>> >>> On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman wrote: >>> Thread.stop is inherently unsafe and has been deprecated since Java 1.2 (1998). It's time to terminally deprecate this method so it can be degraded and removed in the future. This PR does not propose any changes to the JVM TI StopThread function (or the corresponding JDWP command or JDI method). >>> >>> Past time for this to go. >>> >>> >
Re: RFR: 8277861: Terminally deprecate Thread.stop
On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman wrote: > Thread.stop is inherently unsafe and has been deprecated since Java 1.2 > (1998). It's time to terminally deprecate this method so it can be degraded > and removed in the future. > > This PR does not propose any changes to the JVM TI StopThread function (or > the corresponding JDWP command or JDI method). Approved with extreme prejudice. :) - Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6616
Re: RFR: 8277861: Terminally deprecate Thread.stop
On 1/12/2021 3:13 am, Alan Snyder wrote: Although I understand the potential dangers of using Thread.stop, it seems to me there are cases where its use is legitimate and valuable. No there really aren't. :) The perceived utility of stop() is an illusion. It is almost impossible to write any non-trivial code that is async-exception-safe and no JDK library code is written to be async-exception-safe including thread tear-down. So while you can say "stop() is the only way to disrupt this piece of code", you cannot ensure that it is disrupted safely. Once stop is used you need to throw away _all_ stateful objects that may have been in active use while ThreadDeath was propagated. And even during propagation you can easily trigger secondary exceptions. Cheers, David The examples I am thinking of involve a potentially long running computation whose result is no longer needed. In particular, I am thinking of pure computations such as image analysis or audio analysis that do not involve waiting (so that interrupt is not useful) and probably are implemented using some C library (which is not feasible to modify to insert code to support graceful interruption). Is there some alternative that can be used in such cases? Perhaps a version of stop() that only works if no locks are held? Alan On Nov 30, 2021, at 7:51 AM, Roger Riggs wrote: On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman wrote: Thread.stop is inherently unsafe and has been deprecated since Java 1.2 (1998). It's time to terminally deprecate this method so it can be degraded and removed in the future. This PR does not propose any changes to the JVM TI StopThread function (or the corresponding JDWP command or JDI method). Past time for this to go.
Re: RFR: 8277861: Terminally deprecate Thread.stop
I think you are saying that to kill a thread running native code I would need to use native code. Is that right? > On Nov 30, 2021, at 10:17 AM, Alan Bateman wrote: > > On 30/11/2021 17:13, Alan Snyder wrote: >> Although I understand the potential dangers of using Thread.stop, it seems >> to me there are cases where its use is legitimate and valuable. >> >> The examples I am thinking of involve a potentially long running computation >> whose result is no longer needed. >> In particular, I am thinking of pure computations such as image analysis or >> audio analysis that do not involve waiting (so that interrupt is not useful) >> and probably are implemented using some C library (which is not feasible to >> modify to insert code to support graceful interruption). >> > > JCiP Ch.7 has some good advice on this topic. In general, it needs the task > to poll a cancel status or test Thread.currentThread().isInterrupted() to > check for interrupt. In your scenario, with image analysis in native code, > then Thread.stop won't help as it would need to return from the native code > to detect the async exception. > > -Alan >
Re: RFR: 8277861: Terminally deprecate Thread.stop
On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman wrote: > Thread.stop is inherently unsafe and has been deprecated since Java 1.2 > (1998). It's time to terminally deprecate this method so it can be degraded > and removed in the future. > > This PR does not propose any changes to the JVM TI StopThread function (or > the corresponding JDWP command or JDI method). Let's this go away! 😍 - Marked as reviewed by uschindler (Author). PR: https://git.openjdk.java.net/jdk/pull/6616
Re: RFR: 8277861: Terminally deprecate Thread.stop
On 30/11/2021 17:13, Alan Snyder wrote: Although I understand the potential dangers of using Thread.stop, it seems to me there are cases where its use is legitimate and valuable. The examples I am thinking of involve a potentially long running computation whose result is no longer needed. In particular, I am thinking of pure computations such as image analysis or audio analysis that do not involve waiting (so that interrupt is not useful) and probably are implemented using some C library (which is not feasible to modify to insert code to support graceful interruption). JCiP Ch.7 has some good advice on this topic. In general, it needs the task to poll a cancel status or test Thread.currentThread().isInterrupted() to check for interrupt. In your scenario, with image analysis in native code, then Thread.stop won't help as it would need to return from the native code to detect the async exception. -Alan
Re: RFR: 8277861: Terminally deprecate Thread.stop
On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman wrote: > Thread.stop is inherently unsafe and has been deprecated since Java 1.2 > (1998). It's time to terminally deprecate this method so it can be degraded > and removed in the future. > > This PR does not propose any changes to the JVM TI StopThread function (or > the corresponding JDWP command or JDI method). Marked as reviewed by mchung (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6616
Re: RFR: 8277861: Terminally deprecate Thread.stop
Although I understand the potential dangers of using Thread.stop, it seems to me there are cases where its use is legitimate and valuable. The examples I am thinking of involve a potentially long running computation whose result is no longer needed. In particular, I am thinking of pure computations such as image analysis or audio analysis that do not involve waiting (so that interrupt is not useful) and probably are implemented using some C library (which is not feasible to modify to insert code to support graceful interruption). Is there some alternative that can be used in such cases? Perhaps a version of stop() that only works if no locks are held? Alan > On Nov 30, 2021, at 7:51 AM, Roger Riggs wrote: > > On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman wrote: > >> Thread.stop is inherently unsafe and has been deprecated since Java 1.2 >> (1998). It's time to terminally deprecate this method so it can be degraded >> and removed in the future. >> >> This PR does not propose any changes to the JVM TI StopThread function (or >> the corresponding JDWP command or JDI method). > > Past time for this to go. > >
Re: RFR: 8277861: Terminally deprecate Thread.stop
On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman wrote: > Thread.stop is inherently unsafe and has been deprecated since Java 1.2 > (1998). It's time to terminally deprecate this method so it can be degraded > and removed in the future. > > This PR does not propose any changes to the JVM TI StopThread function (or > the corresponding JDWP command or JDI method). Past time for this to go. - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6616
RFR: 8277861: Terminally deprecate Thread.stop
Thread.stop is inherently unsafe and has been deprecated since Java 1.2 (1998). It's time to terminally deprecate this method so it can be degraded and removed in the future. This PR does not propose any changes to the JVM TI StopThread function (or the corresponding JDWP command or JDI method). - Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/6616/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6616&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277861 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6616.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6616/head:pull/6616 PR: https://git.openjdk.java.net/jdk/pull/6616
