On Thu, 22 Sep 2022 22:41:21 GMT, Roger Riggs wrote:
>> Clear the signal mask of the child when launching with posix_spawn.
>>
>> SIGQUIT signals are handled on non-Java Threads by the VM.
>> For Java threads the signal mask blocks SIGQUIT.
>> The ProcessBuilder uses posix_spawn on all platfor
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 Thu, 22 Sep 2022 22:41:21 GMT, Roger Riggs wrote:
>> Clear the signal mask of the child when launching with posix_spawn.
>>
>> SIGQUIT signals are handled on non-Java Threads by the VM.
>> For Java threads the signal mask blocks SIGQUIT.
>> The ProcessBuilder uses posix_spawn on all platfor
On Thu, 22 Sep 2022 22:41:21 GMT, Roger Riggs wrote:
>> Clear the signal mask of the child when launching with posix_spawn.
>>
>> SIGQUIT signals are handled on non-Java Threads by the VM.
>> For Java threads the signal mask blocks SIGQUIT.
>> The ProcessBuilder uses posix_spawn on all platfor
On Fri, 23 Sep 2022 22:10:03 GMT, Naoto Sato wrote:
> The current makefile for `tzdb.dat` won't recompile if some dependent files
> (e.g. `VERSION`) are updated. Adding all files under the tzdb directory to
> the dependency will fix this issue.
Marked as reviewed by joehw (Reviewer).
The current makefile for `tzdb.dat` won't recompile if some dependent files
(e.g. `VERSION`) are updated. Adding all files under the tzdb directory to the
dependency will fix this issue.
-
Commit messages:
- 8294317: Insufficient build rules for tzdb.dat
Changes: https://git.openj
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 Tue, 20 Sep 2022 04:05:56 GMT, Alexander Matveev
wrote:
>> Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850)
>> never set correct value in .jpackage.xml to mark image as signed.
>> [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value
>> to ch
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 Tue, 20 Sep 2022 04:05:56 GMT, Alexander Matveev
wrote:
>> Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850)
>> never set correct value in .jpackage.xml to mark image as signed.
>> [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value
>> to ch
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 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 Tue, 20 Sep 2022 18:08:23 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
On Fri, 23 Sep 2022 17:38:47 GMT, Sean Mullan wrote:
> As a side comment, I notice that `JarInputStream` capitalizes "JAR", whereas
> `JarFile` does not ("jar"). We should really be consistent in our javadocs. I
> think "JAR" is more correct, mainly because that is what the Jar File
> specific
On Tue, 20 Sep 2022 18:08:23 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
On Fri, 23 Sep 2022 03:25:49 GMT, Thomas Stuefe wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move clearing of the signal mask to jspawnhelper so the launched
>> process gets a clear signal mask.
>
> test/jdk/ja
On Thu, 22 Sep 2022 23:13:59 GMT, David Holmes wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move clearing of the signal mask to jspawnhelper so the launched
>> process gets a clear signal mask.
>
> src/java.bas
> 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 11:03:52 GMT, Jie Fu wrote:
> Hi all,
>
> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just
> remove it.
>
> Thanks.
> Best regards,
> Jie
This pull request has now been integrated.
Changeset: 2e20e7ec
Author:Jie Fu
URL:
https://git.open
On Fri, 23 Sep 2022 11:03:52 GMT, Jie Fu wrote:
> Hi all,
>
> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just
> remove it.
>
> Thanks.
> Best regards,
> Jie
Thank you all for the review.
-
PR: https://git.openjdk.org/jdk/pull/10406
On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov
wrote:
> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic
> turned out to be profitable on RISC-V using the same fclass instruction as
> for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it
> ad
On Fri, 23 Sep 2022 11:03:52 GMT, Jie Fu wrote:
> Hi all,
>
> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just
> remove it.
>
> Thanks.
> Best regards,
> Jie
Sorry for this, the change to this tool used in the make file ended up with the
cleanups to tests. Doing it no
On Fri, 23 Sep 2022 06:56:20 GMT, Hao Sun wrote:
>> make/modules/java.base/lib/CoreLibraries.gmk line 52:
>>
>>> 50: CFLAGS_aix := -qfloat=nomaf, \
>>> 51: DISABLED_WARNINGS_gcc := sign-compare misleading-indentation \
>>> 52: array-bounds maybe-uninitialized, \
>>
>> Something
On Fri, 23 Sep 2022 11:03:52 GMT, Jie Fu wrote:
> Hi all,
>
> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just
> remove it.
>
> Thanks.
> Best regards,
> Jie
Good!
-
Marked as reviewed by shade (Reviewer).
PR: https://git.openjdk.org/jdk/pull/10406
On Tue, 20 Sep 2022 10:37:41 GMT, David Holmes wrote:
>> This update is primarily about changes to the JNI Invocation API
>> specification, mainly in relation to `DestroyJavaVM`. The motivation for the
>> changes is to align with changes being made to the JLS, JVMS and
>> `java.lang.Runtime`,
On Fri, 23 Sep 2022 11:03:52 GMT, Jie Fu wrote:
> Hi all,
>
> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just
> remove it.
>
> Thanks.
> Best regards,
> Jie
👍
-
Marked as reviewed by ihse (Reviewer).
PR: https://git.openjdk.org/jdk/pull/10406
On Fri, 23 Sep 2022 12:23:53 GMT, Aleksey Shipilev wrote:
> I think it is also better be named "Remove use of ThreadDeath from make
> utilities" :)
Done.
Thanks.
-
PR: https://git.openjdk.org/jdk/pull/10406
On Fri, 23 Sep 2022 12:20:09 GMT, Jie Fu wrote:
> > Fix is good but change bug type to subtask as Shipilev says.
>
> Done. Thanks @magicus and @shipilev .
I think it is also better be named "Remove use of ThreadDeath from make
utilities" :)
-
PR: https://git.openjdk.org/jdk/pull/
On Fri, 23 Sep 2022 12:09:46 GMT, Magnus Ihse Bursie wrote:
> Fix is good but change bug type to subtask as Shipilev says.
Done.
Thanks @magicus and @shipilev .
-
PR: https://git.openjdk.org/jdk/pull/10406
On Fri, 23 Sep 2022 11:03:52 GMT, Jie Fu wrote:
> Hi all,
>
> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just
> remove it.
>
> Thanks.
> Best regards,
> Jie
Fix is good but change bug type to subtask as Shipilev says.
In that case it sounds fine. I was worried you'd
On Fri, 23 Sep 2022 11:34:33 GMT, Aleksey Shipilev wrote:
>> Hi all,
>>
>> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just
>> remove it.
>>
>> Thanks.
>> Best regards,
>> Jie
>
> This looks fine, and the current use of `ThreadDeath` does not even seem
> correct (you h
On Fri, 23 Sep 2022 11:34:33 GMT, Aleksey Shipilev wrote:
>> Hi all,
>>
>> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just
>> remove it.
>>
>> Thanks.
>> Best regards,
>> Jie
>
> This looks fine, and the current use of `ThreadDeath` does not even seem
> correct (you h
On Fri, 23 Sep 2022 11:03:52 GMT, Jie Fu wrote:
> Hi all,
>
> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just
> remove it.
>
> Thanks.
> Best regards,
> Jie
This looks fine, and the current use of `ThreadDeath` does not even seem
correct (you have to rethrow it). But
Hi all,
Since `ThreadDeath` would be deprecated soon, I assume it's fine to just remove
it.
Thanks.
Best regards,
Jie
-
Commit messages:
- 8294271: make bootcycle-images fails after JDK-8289610
Changes: https://git.openjdk.org/jdk/pull/10406/files
Webrev: https://webrevs.openjdk
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 Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov
wrote:
> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic
> turned out to be profitable on RISC-V using the same fclass instruction as
> for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it
> ad
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 Mon, 19 Sep 2022 10:25:50 GMT, Aleksey Shipilev wrote:
> Reliably reproduces on x86-32 with FPU:
>
>
> $ CONF=linux-x86-server-fastdebug make test
> TEST=java/lang/Float/Binary16ConversionNaN.java TEST_VM_OPTS="-XX:UseAVX=0
> -XX:UseSSE=0"
> ...
> Roundtrip failure on NaN value 7de2 got ba
On Thu, 22 Sep 2022 18:48:41 GMT, Aleksey Shipilev wrote:
>> Reliably reproduces on x86-32 with FPU:
>>
>>
>> $ CONF=linux-x86-server-fastdebug make test
>> TEST=java/lang/Float/Binary16ConversionNaN.java TEST_VM_OPTS="-XX:UseAVX=0
>> -XX:UseSSE=0"
>> ...
>> Roundtrip failure on NaN value 7de
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
On Thu, 22 Sep 2022 09:35:47 GMT, Andrew Haley wrote:
>> This warning seems to be a false positive, because 1) array "fq" with
>> elements from index 0 to "jz" has already been initialized as "fw" at line
>> 290 [1], and 2) variable "jz" should be non-negative from the comment at
>> line 99 [2
53 matches
Mail list logo
