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

On Sat, 8 May 2021 15:40:53 GMT, Paul Sandoz wrote: > Looks good. Someone from the HotSpot side needs to review related changes. > > The way i read the perf numbers is that on non AVX512 systems the numbers are > in the noise (no worse, no better), with significant improvement on AVX512. Hi

Re: RFR: 8266784: java/text/Collator/RuleBasedCollatorTest.java fails with jtreg 6

On Mon, 10 May 2021 23:12:04 GMT, Naoto Sato wrote: > Please review this test case fix for the upcoming jtreg 6. The test was using > `@BeforeGroups` annotation, and the behavior of it has changed in TestNG 7.1 > so that it is only issued when the test was configured with filtering. > Changed

Re: RFR: 8266456: Replace direct TKit.run() calls with jdk.jpackage.test.Annotations.Test annotation [v2]

On Sat, 8 May 2021 01:44:46 GMT, Alexander Matveev wrote: >> - Replaced direct TKit.run() calls with Test annotation. >> - Increased timeout for SigningPackageTest from default to 360 due to >> timeout. This is regression from JDK-8248904 due to changes done in signing >> and

Re: RFR: 8266456: Replace direct TKit.run() calls with jdk.jpackage.test.Annotations.Test annotation [v3]

> - Replaced direct TKit.run() calls with Test annotation. > - Increased timeout for SigningPackageTest from default to 360 due to > timeout. This is regression from JDK-8248904 due to changes done in signing > and --remove-signature adds additional time since it is run per file. > - Fixed

RFR: 8266857: PipedOutputStream.sink should be volatile

8266857: PipedOutputStream.sink should be volatile - Commit messages: - 8266857: PipedOutputStream.sink should be volatile Changes: https://git.openjdk.java.net/jdk/pull/3960/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3960=00 Issue:

RFR: 8266784: java/text/Collator/RuleBasedCollatorTest.java fails with jtreg 6

Please review this test case fix for the upcoming jtreg 6. The test was using `@BeforeGroups` annotation, and the behavior of it has changed in TestNG 7.1 so that it is only issued when the test was configured with filtering. Changed to use `@BeforeClass` instead. - Commit

Re: Review CSR JDK-8266760: Remove sun.misc.Unsafe::defineAnonymousClass

Thank you all. Mandy On 5/10/21 2:27 PM, Paul Sandoz wrote: Looks good, I took the liberty of making some minor edits, mostly fixing some typos. Paul. On May 10, 2021, at 12:26 PM, Mandy Chung wrote: Hidden classes were added in Java SE 15. Class data support was added in 16.

Re: RFR: 8266317: Vector API enhancements [v3]

> This PR contains API and implementation changes for [JEP-414 Vector API > (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for > when targeted. > > Enhancements are made to the API for the support of operations on characters, > such as for UTF-8 character decoding.

Integrated: 8265128: [REDO] Optimize Vector API slice and unslice operations

On Thu, 29 Apr 2021 21:29:03 GMT, Sandhya Viswanathan wrote: > All the slice and unslice variants that take more than one argument can > benefit from already intrinsic methods on similar lines as slice(origin) and > unslice(origin). > > Changes include: > * Rewrite Vector API slice/unslice

Re: Would lambda expressions be meaningful annotation properties?

Yes, this has been considered at some length.  The summary verdict is:  - Method references for static/unbound methods seem like reasonable constant literals to put in annotations, not unlike class literals.  - Lambdas, on the other hand: absolutely, positively, not. To actually get to method

Re: RFR: 8265128: [REDO] Optimize Vector API slice and unslice operations [v4]

On Mon, 10 May 2021 18:31:30 GMT, Sandhya Viswanathan wrote: >> All the slice and unslice variants that take more than one argument can >> benefit from already intrinsic methods on similar lines as slice(origin) and >> unslice(origin). >> >> Changes include: >> * Rewrite Vector API

Re: RFR: 8266317: Vector API enhancements [v2]

On Mon, 10 May 2021 21:37:25 GMT, Paul Sandoz wrote: >> This PR contains API and implementation changes for [JEP-414 Vector API >> (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for >> when targeted. >> >> Enhancements are made to the API for the support of operations

Would lambda expressions be meaningful annotation properties?

Hello, I was wondering if there was ever any consideration of allowing (stateless) lambda expressions as annotation members. As an example, this would make the following lambda expression possible: @interface MyAnnotation { Supplier value(); } In many enterprise applications, this would be a

Re: RFR: 8266317: Vector API enhancements [v2]

> This PR contains API and implementation changes for [JEP-414 Vector API > (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for > when targeted. > > Enhancements are made to the API for the support of operations on characters, > such as for UTF-8 character decoding.

Re: RFR: 8266317: Vector API enhancements [v2]

On Mon, 10 May 2021 21:05:02 GMT, Vladimir Ivanov wrote: >> Paul Sandoz has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Rename method. > > src/hotspot/cpu/aarch64/aarch64.ad line 2440: > >> 2438: } >> 2439: >> 2440: bool

Re: Review CSR JDK-8266760: Remove sun.misc.Unsafe::defineAnonymousClass

Looks good, I took the liberty of making some minor edits, mostly fixing some typos. Paul. > On May 10, 2021, at 12:26 PM, Mandy Chung wrote: > > Hidden classes were added in Java SE 15. Class data support was added in 16. > `sun.misc.Unsafe::defineAnonymousClass` was deprecated in JDK 15

Re: RFR: 8266317: Vector API enhancements

On Thu, 29 Apr 2021 21:13:38 GMT, Paul Sandoz wrote: > This PR contains API and implementation changes for [JEP-414 Vector API > (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for > when targeted. > > Enhancements are made to the API for the support of operations on

Re: RFR: 8265128: [REDO] Optimize Vector API slice and unslice operations [v4]

On Mon, 10 May 2021 18:31:30 GMT, Sandhya Viswanathan wrote: >> All the slice and unslice variants that take more than one argument can >> benefit from already intrinsic methods on similar lines as slice(origin) and >> unslice(origin). >> >> Changes include: >> * Rewrite Vector API

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3]

On Fri, 30 Apr 2021 17:20:21 GMT, Mandy Chung wrote: >>> I think the implementation does not support that. I will also need to look >>> into how this impacts JDK-8266010. As I suggest earlier, I'm fine to do >>> this as a follow up after integration. >> >> I've added `@CS` in the interface

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v16]

> This PR contains the API and implementation changes for JEP-412 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull

Re: Review CSR JDK-8266760: Remove sun.misc.Unsafe::defineAnonymousClass

- Mail original - > De: "mandy chung" > À: "core-libs-dev" , "valhalla-dev" > > Envoyé: Lundi 10 Mai 2021 21:26:33 > Objet: Review CSR JDK-8266760: Remove sun.misc.Unsafe::defineAnonymousClass > Hidden classes were added in Java SE 15. Class data support was added in > 16.

Review CSR JDK-8266760: Remove sun.misc.Unsafe::defineAnonymousClass

Hidden classes were added in Java SE 15. Class data support was added in 16. `sun.misc.Unsafe::defineAnonymousClass` was deprecated in JDK 15 and deprecated for terminally removal in JDK 16. I propose to remove `sun.misc.Unsafe::defineAnonymousClass` from JDK 17: CSR:

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v15]

On Mon, 10 May 2021 18:15:01 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8265128: [REDO] Optimize Vector API slice and unslice operations [v4]

On Mon, 10 May 2021 18:31:30 GMT, Sandhya Viswanathan wrote: >> All the slice and unslice variants that take more than one argument can >> benefit from already intrinsic methods on similar lines as slice(origin) and >> unslice(origin). >> >> Changes include: >> * Rewrite Vector API

Integrated: 8265208: [JEP-356] : SplittableRandom and SplittableGenerators - splits() methods does not throw NullPointerException when source is null

On Wed, 14 Apr 2021 17:33:30 GMT, Jim Laskey wrote: > Add check for null. This pull request has now been integrated. Changeset: 0cc7833f Author:Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/0cc7833f3d84971dd03a9a620585152a6debb40e Stats: 2 lines in 1 file changed: 2

Re: RFR: 8265128: [REDO] Optimize Vector API slice and unslice operations [v3]

On Fri, 30 Apr 2021 23:34:15 GMT, Paul Sandoz wrote: >>> @PaulSandoz would it be possible for you to run this through your testing? >> >> Started, will report back when done. > >> > @PaulSandoz would it be possible for you to run this through your testing? >> >> Started, will report back when

Re: RFR: 8265128: [REDO] Optimize Vector API slice and unslice operations [v4]

> All the slice and unslice variants that take more than one argument can > benefit from already intrinsic methods on similar lines as slice(origin) and > unslice(origin). > > Changes include: > * Rewrite Vector API slice/unslice using already intrinsic methods > * Fix in

Re: RFR: 8265208: [JEP-356] : SplittableRandom and SplittableGenerators - splits() methods does not throw NullPointerException when source is null [v2]

On Mon, 10 May 2021 18:17:30 GMT, Jim Laskey wrote: >> Add check for null. > > Jim Laskey has updated the pull request with a new target base due to a merge > or a rebase. The pull request now contains four commits: > > - Merge branch 'master' into 8265208 > - Check for null source > - Make

Re: RFR: 8265208: [JEP-356] : SplittableRandom and SplittableGenerators - splits() methods does not throw NullPointerException when source is null [v2]

> Add check for null. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into 8265208 - Check for null source - Make makeXXXSpliterator final - Move makeXXXSpilterator from public

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v15]

> This PR contains the API and implementation changes for JEP-412 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull

Re: RFR: 8264777: Overload optimized FileInputStream::readAllBytes [v7]

> Please consider this request to override the `java.io.InputStream` methods > `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more > performant implementations. The method overrides attempt to read all > requested bytes into a single array of the required size rather than >

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v14]

> This PR contains the API and implementation changes for JEP-412 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull

RFR: CSR JDK-8266553 Technical corrections to java/util/random/package-info.java

Could I get a CSR review. Technical clarification in the javadoc. Cheers, -- Jim CSR: https://bugs.openjdk.java.net/browse/JDK-8266553 PR: https://github.com/openjdk/jdk/pull/3881 Bug:

Integrated: 8266603: jpackage: Add missing copyright file in Java runtime .deb installers

On Thu, 6 May 2021 01:22:41 GMT, Alexey Semenyuk wrote: > jpackage should create copyright file in /usr/share/doc directory tree when > building .deb package for Java runtime with installation directory in /usr > directory tree. > > jpackage creates share/doc/copyright file in installation

Re: RFR: 8266603: jpackage: Add missing copyright file in Java runtime .deb installers [v2]

On Fri, 7 May 2021 19:57:17 GMT, Alexey Semenyuk wrote: >> jpackage should create copyright file in /usr/share/doc directory tree when >> building .deb package for Java runtime with installation directory in /usr >> directory tree. >> >> jpackage creates share/doc/copyright file in

Integrated: 8266774: System property values for stdout/err on Windows UTF-8

On Fri, 7 May 2021 22:46:08 GMT, Naoto Sato wrote: > Please review this small fix to Windows system property init code. This is > leftover from the support for `Console.charset()` method, where it lacked to > initialize `sun.stdout/err.encoding` to `UTF-8` for the code page `cp65001`. > The

Re: RFR: 8266456: Replace direct TKit.run() calls with jdk.jpackage.test.Annotations.Test annotation [v2]

On Fri, 7 May 2021 23:07:02 GMT, Alexander Matveev wrote: >> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Functional.java line 161: >> >>> 159: } >>> 160: >>> 161: if >>> (throwable.getClass().getName().equals("jtreg.SkippedException")) { >> >> Would it make sense to

Re: RFR: 8266456: Replace direct TKit.run() calls with jdk.jpackage.test.Annotations.Test annotation [v2]

On Sat, 8 May 2021 01:44:46 GMT, Alexander Matveev wrote: >> - Replaced direct TKit.run() calls with Test annotation. >> - Increased timeout for SigningPackageTest from default to 360 due to >> timeout. This is regression from JDK-8248904 due to changes done in signing >> and

Integrated: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari wrote: > this change will include the below headers files to Linux only. > #include > #include This pull request has now been integrated. Changeset: b823b3ef Author:Vyom Tewari URL:

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 10:31:40 GMT, Aleksey Shipilev wrote: >> No, change is specific to Linux. Please >> see(https://github.com/openjdk/jdk/commit/69b96f9a1b4a959c6b86f41c2259d9e4d47c8ede). > > OK, so what you are saying is that the path that references `S_ISBLK` is > protected by

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari wrote: > this change will include the below headers files to Linux only. > #include > #include src/java.base/unix/native/libjava/io_util_md.c line 256: > 254: return -1; > 255: } > 256: #if defined(__linux__) &&

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 09:50:44 GMT, Aleksey Shipilev wrote: >> this change will include the below headers files to Linux only. >> #include >> #include > > src/java.base/unix/native/libjava/io_util_md.c line 39: > >> 37: #if defined(__linux__) >> 38: #include >> 39: #include > > Does Mac

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 11:26:30 GMT, Alan Bateman wrote: >> this change will include the below headers files to Linux only. >> #include >> #include > > src/java.base/unix/native/libjava/io_util_md.c line 256: > >> 254: return -1; >> 255: } >> 256: #if defined(__linux__) &&

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 11:09:07 GMT, Vyom Tewari wrote: >> I am not the Mac expert, but i checked on my MacOS Laptop and i did not >> found "BLKGETSIZE64" defined in sys/stat.h. >> As Alan already told that i took the code from FileDispatcherImpl.size0 and >> followed the same pattern. > > I

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 10:59:37 GMT, Vyom Tewari wrote: >> I think Vymon took the code from FileDispatcherImpl_size0, which has been >> compiling on macOS without issues. I don't mind if we fix the issue with >> this PR or just back it out and fix it with another PR. > > I am not the Mac expert,

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 10:27:34 GMT, Vyom Tewari wrote: >> src/java.base/unix/native/libjava/io_util_md.c line 39: >> >>> 37: #if defined(__linux__) >>> 38: #include >>> 39: #include >> >> Does Mac OS need `sys/stat.h`, though? > > No, change is specific to Linux. Please >

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 10:44:10 GMT, Alan Bateman wrote: >> OK, so what you are saying is that the path that references `S_ISBLK` is >> protected by `BLKGETSIZE64` that is guaranteed to be undefined on OS X? If >> so, this is (awkwardly) fine. > > I think Vymon took the code from

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 08:46:15 GMT, Vyom Tewari wrote: > Original fix was intended to Linux specific. Current Fix will not impact > other platforms. Your original fix failed to be Linux specific, so given you never actually tested it on other platforms you don't know whether another part of the

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 11:21:34 GMT, Vyom Tewari wrote: >>> Hi Vyom, >>> >>> That fixes the include file problem but as this was obviously not tested on >>> non-Linux have you checked that the rest of the fix for 8266610 works okay >>> on non-Linux? >>> >>> Thanks, >>> David >> >> Hi David, >>

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari wrote: > this change will include the below headers files to Linux only. > #include > #include somehow tests not working for me. https://github.com/vyommani/jdk/actions/runs/827989185 - PR:

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 13:01:45 GMT, Jayathirth D V wrote: > In internal CI with fix tier 1 builds are running fine. Ok i will integrate my changes now. - PR: https://git.openjdk.java.net/jdk/pull/3943

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 08:46:15 GMT, Vyom Tewari wrote: >> Hi Vyom, >> >> That fixes the include file problem but as this was obviously not tested on >> non-Linux have you checked that the rest of the fix for 8266610 works okay >> on non-Linux? >> >> Thanks, >> David > >> Hi Vyom, >> >> That

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari wrote: > this change will include the below headers files to Linux only. > #include > #include The fix to 8266610 caused a build failure on macOS. What is your plan to make sure this won't happen with this change? I would recommend enabling

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 08:46:15 GMT, Vyom Tewari wrote: >> Hi Vyom, >> >> That fixes the include file problem but as this was obviously not tested on >> non-Linux have you checked that the rest of the fix for 8266610 works okay >> on non-Linux? >> >> Thanks, >> David > >> Hi Vyom, >> >> That

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 11:21:34 GMT, Vyom Tewari wrote: >>> Hi Vyom, >>> >>> That fixes the include file problem but as this was obviously not tested on >>> non-Linux have you checked that the rest of the fix for 8266610 works okay >>> on non-Linux? >>> >>> Thanks, >>> David >> >> Hi David, >>

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 07:39:44 GMT, David Holmes wrote: > Hi Vyom, > > That fixes the include file problem but as this was obviously not tested on > non-Linux have you checked that the rest of the fix for 8266610 works okay on > non-Linux? > > Thanks, > David Hi David, Original fix was

RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException

During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an

Re: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException

On Sun, 9 May 2021 21:59:29 GMT, Rafael Winterhalter wrote: > During annotation parsing, the parser assumes that a declared property is of > an array type if the parsed annotation property is defined as an array. In > this case, the component type is `null`, and a `NullPointerException` is >

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari wrote: > this change will include the below headers files to Linux only. > #include > #include MacOS builds fail with GHA since recently. So enabling GHA would serve a basic test for this to work.

RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

this change will include the below headers files to Linux only. #include #include - Commit messages: - fixed the indentation - added the additional check so that modified code get executed on linux only. - JDK-8266797: Fix for 8266610 breaks the build on macos Changes:

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari wrote: > this change will include the below headers files to Linux only. > #include > #include Marked as reviewed by jdv (Reviewer). In internal CI with fix tier 1 builds are running fine. - PR:

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari wrote: > this change will include the below headers files to Linux only. > #include > #include Hi Vyom, That fixes the include file problem but as this was obviously not tested on non-Linux have you checked that the rest of the fix for

Re: [External] : Re: Proposal to add JavaScript platform to jpackage

Regardless of whether you integrate into jpackage or provide a new "jspackage" tool, this presupposes the capability of running a set of Java class files on top of a JavaScript engine. Pointing to a third-party library that happens to implement this isn't sufficient to define this new

JDK Dynalink only works with unconditionally exported packages

Hi all. I've been testing the JDK Dynalink recently and I think I've found a bug. The class jdk.dynalink.beans.CheckRestrictedPackage checks if a package is restricted. So, I have a class that has some static methods. But to Dynalink find the class, the class needs to be public. OK, I've

Re: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v5]

On Fri, 7 May 2021 03:10:32 GMT, Jason Zaugg wrote: >> If the given Path represents a file, use the overload of read defined >> in FileChannel that accepts an explicit position and avoid serializing >> reads. >> >> Note: The underlying NIO implementation is not required to implement >>

Re: Collection::getAny discussion

- Mail original - > De: "Stephen Colebourne" > À: "core-libs-dev" > Envoyé: Vendredi 30 Avril 2021 23:15:45 > Objet: Re: Collection::getAny discussion > On Fri, 30 Apr 2021 at 19:50, Stuart Marks wrote: >> You're asking for something that's somewhat different, which you called the >>

Re: [External] : Re: ReversibleCollection proposal

- Mail original - > De: "dfranken jdk" > À: "Remi Forax" , "Stuart Marks" > Cc: "core-libs-dev" > Envoyé: Dimanche 9 Mai 2021 12:13:58 > Objet: Re: [External] : Re: ReversibleCollection proposal > When I thought about Collection's role in the hierarchy, it seemed to > me that