Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3]

2021-07-15 Thread David Holmes
On Thu, 15 Jul 2021 15:54:50 GMT, Jorn Vernee wrote: >> This patch rewrites the prologue and epilogue of panama upcalls, in order to >> fix the test failure from the title. >> >> Previously, we did a call to potentially attach the current thread to the >> VM, and then afterwards did the same

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-15 Thread David Holmes
On Thu, 15 Jul 2021 10:47:17 GMT, Jorn Vernee wrote: >> src/hotspot/share/prims/universalUpcallHandler.cpp line 121: >> >>> 119: } >>> 120: >>> 121: MACOS_AARCH64_ONLY(thread->enable_wx(WXExec)); >> >> Not clear why this is needed? JavaCallWrapper doesn't use it. > > I took this from

Re: RFR: 8266054: VectorAPI rotate operation optimization [v10]

2021-07-15 Thread Sandhya Viswanathan
On Thu, 15 Jul 2021 08:34:42 GMT, Jatin Bhateja wrote: >> Current VectorAPI Java side implementation expresses rotateLeft and >> rotateRight operation using following operations:- >> >> vec1 = lanewise(VectorOperators.LSHL, n) >> vec2 = lanewise(VectorOperators.LSHR, n) >> res =

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-15 Thread Vladimir Kozlov
On Thu, 15 Jul 2021 12:44:23 GMT, Jorn Vernee wrote: >> Thanks. >> >> I've been careful here to return a `Thread*` since the result is stored in >> `r15_thread` and I thought converting between sub and super types could >> potentially result in different pointers due to the way super types

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3]

2021-07-15 Thread David Holmes
On Thu, 15 Jul 2021 11:02:21 GMT, Jorn Vernee wrote: >> How does native code reach a safepoint polling point? > > The stack trace looks like this: > > > Current thread (0x02a2489f0b50): JavaThread "Thread-4551" > [_thread_in_Java, id=24920, stack(0x00d9e050,0x00d9e060)] >

Re: RFR: 8260265: UTF-8 by Default [v4]

2021-07-15 Thread Naoto Sato
> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of > the changes is `Charset.defaultCharset()` returning `UTF-8` and > `file.encoding` system property being added in the spec, but another notable > modification is in `java.io.PrintStream` where it continues to use the

Integrated: JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

2021-07-15 Thread Andy Herrick
On Thu, 8 Jul 2021 19:25:33 GMT, Andy Herrick wrote: > JDK-8269387: jpackage --add-launcher should have option to not create > shortcuts for additional launchers This pull request has now been integrated. Changeset: 057992f2 Author:Andy Herrick URL:

Re: RFR: 8075806: divideExact is missing in java.lang.Math [v4]

2021-07-15 Thread Brian Burkhalter
> Please consider this proposal to add `divideExact()` methods for integral > data types to `java.lang.Math` thereby rounding out "exact" support to all > four basic arithmetic operations. Brian Burkhalter has refreshed the contents of this pull request, and previous commits have been removed.

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3]

2021-07-15 Thread Jorn Vernee
On Thu, 15 Jul 2021 15:54:50 GMT, Jorn Vernee wrote: >> This patch rewrites the prologue and epilogue of panama upcalls, in order to >> fix the test failure from the title. >> >> Previously, we did a call to potentially attach the current thread to the >> VM, and then afterwards did the same

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3]

2021-07-15 Thread Jorn Vernee
> This patch rewrites the prologue and epilogue of panama upcalls, in order to > fix the test failure from the title. > > Previously, we did a call to potentially attach the current thread to the VM, > and then afterwards did the same suspend and stack reguard checks that we do > on the

Re: RFR: 8075806: divideExact is missing in java.lang.Math [v3]

2021-07-15 Thread Brian Burkhalter
> Please consider this proposal to add `divideExact()` methods for integral > data types to `java.lang.Math` thereby rounding out "exact" support to all > four basic arithmetic operations. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last

Re: RFR: 8270547: java.util.Random contains unnecessary @SuppressWarnings("exports")

2021-07-15 Thread Brian Burkhalter
On Thu, 15 Jul 2021 12:07:42 GMT, Jan Lahoda wrote: > Removing unnecessary `@SuppressWarnings("exports")`. The reason for the > suppress warnings was, as far as I can tell, removed by > https://bugs.openjdk.java.net/browse/JDK-8265137. +1 - Marked as reviewed by bpb (Reviewer).

Re: RFR: 8270547: java.util.Random contains unnecessary @SuppressWarnings("exports")

2021-07-15 Thread Joe Darcy
On Thu, 15 Jul 2021 12:07:42 GMT, Jan Lahoda wrote: > Removing unnecessary `@SuppressWarnings("exports")`. The reason for the > suppress warnings was, as far as I can tell, removed by > https://bugs.openjdk.java.net/browse/JDK-8265137. Looks fine. - Marked as reviewed by darcy

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v4]

2021-07-15 Thread Severin Gehwolf
On Thu, 15 Jul 2021 13:09:54 GMT, Matthias Baesken wrote: >> Hello, please review this PR; it extend the OSContainer API in order to also >> support the pids controller of cgroups. >> >> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", >> "memory" on some older Linux

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v2]

2021-07-15 Thread Matthias Baesken
On Fri, 9 Jul 2021 13:53:27 GMT, Matthias Baesken wrote: > > OK. Please also add a test on the hotspot side. You may want to add > > relevant parts to `TestMisc.java`. > > Thanks for the suggestion, I will look into TestMisc.java . I added some HS testing code in the latest commit. Best

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v4]

2021-07-15 Thread Matthias Baesken
> Hello, please review this PR; it extend the OSContainer API in order to also > support the pids controller of cgroups. > > I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", > "memory" on some older Linux distros (SLES 12.1, RHEL 7.1) the pids > controller might not be

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-15 Thread David Holmes
On 15/07/2021 10:29 pm, Jorn Vernee wrote: On Wed, 14 Jul 2021 00:47:47 GMT, David Holmes wrote: Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Assert frame is correct type in frame_data_for_frame

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-15 Thread Jorn Vernee
On Thu, 15 Jul 2021 12:25:54 GMT, Jorn Vernee wrote: >> src/hotspot/share/prims/universalUpcallHandler.cpp line 76: >> >>> 74: >>> 75: // modelled after JavaCallWrapper::JavaCallWrapper >>> 76: Thread* >>> ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) >>> { >>

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-15 Thread Jorn Vernee
On Wed, 14 Jul 2021 00:58:38 GMT, David Holmes wrote: > The mapping to JavaCallWrapper seems reasonable but there are a few > differences that I'm now assuming stem from the fact upcalls start > _thread_in_native while JCW starts from _thread_in_vm? The main difference stems from the fact

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-15 Thread Jorn Vernee
On Wed, 14 Jul 2021 00:47:47 GMT, David Holmes wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Assert frame is correct type in frame_data_for_frame > > src/hotspot/share/prims/universalUpcallHandler.cpp line 76: >

RFR: 8270547: java.util.Random contains unnecessary @SuppressWarnings("exports")

2021-07-15 Thread Jan Lahoda
Removing unnecessary `@SuppressWarnings("exports")`. The reason for the suppress warnings was, as far as I can tell, removed by https://bugs.openjdk.java.net/browse/JDK-8265137. - Commit messages: - 8270547: java.util.Random contains unnecessary @SuppressWarnings("exports")

Re: RFR: 8270160: Remove redundant bounds check from AbstractStringBuilder.charAt() [v3]

2021-07-15 Thread Сергей Цыпанов
> `AbstractStringBuilder.charAt(int)` does bounds check before calling > `charAt()` (for non-latin Strings): > > @Override > public char charAt(int index) { > checkIndex(index, count); > if (isLatin1()) { > return (char)(value[index] & 0xff); > } > return

Re: RFR: 8270160: Remove redundant bounds check from AbstractStringBuilder.charAt() [v2]

2021-07-15 Thread Сергей Цыпанов
> `AbstractStringBuilder.charAt(int)` does bounds check before calling > `charAt()` (for non-latin Strings): > > @Override > public char charAt(int index) { > checkIndex(index, count); > if (isLatin1()) { > return (char)(value[index] & 0xff); > } > return

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-15 Thread Jorn Vernee
On Wed, 14 Jul 2021 00:50:44 GMT, David Holmes wrote: >> src/hotspot/share/runtime/safepoint.cpp line 931: >> >>> 929: // See if return type is an oop. >>> 930: bool return_oop = nm->method()->is_returning_oop(); >>> 931: HandleMark hm(self); >> >> I was seeing an

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

2021-07-15 Thread Jorn Vernee
On Wed, 14 Jul 2021 00:24:38 GMT, David Holmes wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Assert frame is correct type in frame_data_for_frame > > src/hotspot/share/prims/universalUpcallHandler.cpp line 86: >

Re: RFR: 8266054: VectorAPI rotate operation optimization [v10]

2021-07-15 Thread Jatin Bhateja
> Current VectorAPI Java side implementation expresses rotateLeft and > rotateRight operation using following operations:- > > vec1 = lanewise(VectorOperators.LSHL, n) > vec2 = lanewise(VectorOperators.LSHR, n) > res = lanewise(VectorOperations.OR, vec1 , vec2) > > This patch moves