On Fri, 23 Sep 2022 13:57:56 GMT, Alan Bateman wrote:
>> Degrade Thread.suspend/resume to throw UOE unconditionally.
>>
>> Another step in the removal of this deadlock prone mis-feature from the
>> user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2
>> (1998) and terminal
> Degrade Thread.suspend/resume to throw UOE unconditionally.
>
> Another step in the removal of this deadlock prone mis-feature from the
> user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2
> (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume
> we
On Fri, 23 Sep 2022 21:42:08 GMT, David Holmes wrote:
>> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java
>> line 126:
>>
>>> 124: try {
>>> 125: transportService = transportServices.next();
>>> 126: } catch (Exception | Error x)
On Fri, 23 Sep 2022 21:47:06 GMT, David Holmes wrote:
>> Now that Thread.stop has been degraded to throw
>> `UnsupportedOperationException` (JDK-8299610) the only direct source of
>> async exceptions is from JVMTI `StopThread`. We can remove the
>> `JVM_StopThread` code, remove the `stillborn`
On Fri, 23 Sep 2022 18:21:30 GMT, Chris Plummer wrote:
>> David Holmes has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 16 commits:
>>
>> - Merge branch 'master' into 8293592-JVM_StopThread
>> - Removal all special handling of Th
On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes wrote:
> Now that Thread.stop has been degraded to throw
> `UnsupportedOperationException` (JDK-8299610) the only direct source of async
> exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread`
> code, remove the `stillborn` fie
> Now that Thread.stop has been degraded to throw
> `UnsupportedOperationException` (JDK-8299610) the only direct source of async
> exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread`
> code, remove the `stillborn` field from `java.lang.Thread` and its associated
> accesse
On Fri, 23 Sep 2022 20:38:17 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiThreadState.cpp line 273:
>>
>>> 271:
>>> 272: assert(!thread->is_in_tmp_VTMS_transition(), "sanity check");
>>> 273: assert(!thread->is_in_VTMS_transition(), "VTMS_transition sanity
>>> check");
>
On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote:
>> There are several places in VirtualThread class implementation where virtual
>> threads are being mounted or unmounted, so there is a transition of the
>> JavaThread identity from carrier thread to virtual thread and back. The
>> exec
On Fri, 23 Sep 2022 13:57:56 GMT, Alan Bateman wrote:
>> Degrade Thread.suspend/resume to throw UOE unconditionally.
>>
>> Another step in the removal of this deadlock prone mis-feature from the
>> user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2
>> (1998) and terminal
On Fri, 23 Sep 2022 18:32:57 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 1. addressed review comments from Chris; added VirtualThread.java update
>> from Alan
>
> src/hotspot/share/prims/
On Fri, 23 Sep 2022 17:08:46 GMT, Johan Sjölen wrote:
> Here's a suggested solution for the ticket mentioned and a use case for
> outputStream. I'm not attached to the name.
>
> This saves space for all allocated outputStreams, which is nice. It also
> makes the purpose of ResourceObj more cle
On Fri, 23 Sep 2022 09:30:32 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/runtime/javaThread.hpp line 652:
>>
>>> 650: void set_is_in_VTMS_transition(bool val);
>>> 651: void toggle_is_in_tmp_VTMS_transition(){
>>> _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; };
>>>
On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote:
>> There are several places in VirtualThread class implementation where virtual
>> threads are being mounted or unmounted, so there is a transition of the
>> JavaThread identity from carrier thread to virtual thread and back. The
>> exec
On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes wrote:
> Now that Thread.stop has been degraded to throw
> `UnsupportedOperationException` (JDK-8299610) the only direct source of async
> exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread`
> code, remove the `stillborn` fie
On Mon, 19 Sep 2022 23:02:42 GMT, Leonid Mesnik wrote:
> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread
> whether it is possible.
> Testcase from test
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java
> was removed because only o
Here's a suggested solution for the ticket mentioned and a use case for
outputStream. I'm not attached to the name.
This saves space for all allocated outputStreams, which is nice. It also makes
the purpose of ResourceObj more clear ("please handle the life cycle for me"),
reducing the need for
> Degrade Thread.suspend/resume to throw UOE unconditionally.
>
> Another step in the removal of this deadlock prone mis-feature from the
> user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2
> (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume
> we
On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes wrote:
> Now that Thread.stop has been degraded to throw
> `UnsupportedOperationException` (JDK-8299610) the only direct source of async
> exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread`
> code, remove the `stillborn` fie
On Tue, 20 Sep 2022 22:34:59 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiExport.cpp line 1055:
>>
>>> 1053: if (JavaThread::current()->is_in_tmp_VTMS_transition()) {
>>> 1054: return false;
>>> 1055: }
>>
>> You mentioned this in the PR description. However, it's not cle
On Thu, 22 Sep 2022 20:09:21 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 1. addressed review comments from Chris; added VirtualThread.java update
>> from Alan
>
> src/hotspot/share/runtim
On Tue, 20 Sep 2022 22:41:50 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/runtime/javaThread.cpp line 1174:
>>
>>> 1172: #if INCLUDE_JVMTI
>>> 1173: // Suspending a JavaThread in VTMS transition or disabling VTMS
>>> transitions can cause deadlocks.
>>> 1174: assert(!is_in_non_tmp_VTMS_
On Thu, 22 Sep 2022 15:05:37 GMT, Leonid Mesnik wrote:
>> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread
>> whether it is possible.
>> Testcase from test
>> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java
>> was removed because o
Now that Thread.stop has been degraded to throw `UnsupportedOperationException`
(JDK-8299610) the only direct source of async exceptions is from JVMTI
`StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn`
field from `java.lang.Thread` and its associated accesses from the
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (199
25 matches
Mail list logo
