Integrated: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized*

2021-03-04 Thread Ian Graves
On Tue, 16 Feb 2021 21:57:43 GMT, Ian Graves wrote: > Modify the `unmodifiable*` methods in `java.util.Collections` to be > idempotent. That is, when given an immutable collection from > `java.util.ImmutableCollections` or `java.util.Collections`, these methods > will return the reference

Integrated: 8262300: jpackage app-launcher fails on linux when using JDK11 based runtime

2021-03-04 Thread Alexey Semenyuk
On Thu, 4 Mar 2021 12:32:11 GMT, Alexey Semenyuk wrote: > Fix jpackage app launcher to also look for JLI lib in "lib/jli/libjli.so" > subdirectory of runtime This pull request has now been integrated. Changeset: ee09bada Author:Alexey Semenyuk URL:

Re: RFR: 8262300: jpackage app-launcher fails on linux when using JDK11 based runtime

2021-03-04 Thread Alexander Matveev
On Thu, 4 Mar 2021 12:32:11 GMT, Alexey Semenyuk wrote: > Fix jpackage app launcher to also look for JLI lib in "lib/jli/libjli.so" > subdirectory of runtime Marked as reviewed by almatvee (Committer). - PR: https://git.openjdk.java.net/jdk/pull/2827

Re: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v8]

2021-03-04 Thread Joe Darcy
On Thu, 4 Mar 2021 22:35:09 GMT, Ian Graves wrote: >> Modify the `unmodifiable*` methods in `java.util.Collections` to be >> idempotent. That is, when given an immutable collection from >> `java.util.ImmutableCollections` or `java.util.Collections`, these methods >> will return the reference

Re: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v7]

2021-03-04 Thread Ian Graves
On Thu, 4 Mar 2021 21:37:45 GMT, Joe Darcy wrote: >> Marked as reviewed by smarks (Reviewer). > > If the checks for Navigable set and the like are omitted, I'd prefer to a > comment in the sources noting this is intention as a Navigable set is-a > Sorted set. Added comments to the relevant

Re: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v8]

2021-03-04 Thread Ian Graves
> Modify the `unmodifiable*` methods in `java.util.Collections` to be > idempotent. That is, when given an immutable collection from > `java.util.ImmutableCollections` or `java.util.Collections`, these methods > will return the reference instead of creating a new immutable collection that >

Re: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException [v3]

2021-03-04 Thread Craig Andrews
> `java.net.URLClassLoader.getResource` can throw an undocumented > `IllegalArgumentException`. > > According to the javadoc for the `getResource` and `findResource` methods, > neither should be throwing `IllegalArgumentException` - they should return > null if the resource can't be resolved.

Re: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException [v2]

2021-03-04 Thread Brent Christian
On 3/4/21 1:16 PM, Craig Andrews wrote: @bchristi-git has indicated that a [compatibility and specification](https://wiki.openjdk.java.net/display/csr/Main) (CSR) request is needed for this pull request. @candrews please create a CSR request and add link to it in

Re: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v7]

2021-03-04 Thread Joe Darcy
On Thu, 4 Mar 2021 20:28:58 GMT, Stuart Marks wrote: >> Ian Graves has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert "Avoid wrapping subclasses where relevant. Updated tests." >> >> This reverts commit

Integrated: 8262989: Vectorize VectorShuffle checkIndexes, wrapIndexes and laneIsValid methods

2021-03-04 Thread Sandhya Viswanathan
On Wed, 3 Mar 2021 22:32:48 GMT, Sandhya Viswanathan wrote: > The hot path of VectorShuffle checkIndexes, wrapIndexes and laneIsValid > methods can be implemented using Vector API methods. > > For the attached jmh TestSlice.java, performance improves as below. > > Before: > Benchmark

Re: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException [v2]

2021-03-04 Thread Craig Andrews
> `java.net.URLClassLoader.getResource` can throw an undocumented > `IllegalArgumentException`. > > According to the javadoc for the `getResource` and `findResource` methods, > neither should be throwing `IllegalArgumentException` - they should return > null if the resource can't be resolved.

Re: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException [v2]

2021-03-04 Thread Craig Andrews
On Wed, 3 Mar 2021 18:10:25 GMT, Brent Christian wrote: >The commented-out lines should be removed from the change. Done!  > As Alan said, a regression test will be needed. At minimum, it should test a > method that returns a URL, as well as a method that returns an Enumeration > (which

Re: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v7]

2021-03-04 Thread Stuart Marks
On Thu, 4 Mar 2021 04:13:12 GMT, Ian Graves wrote: >> Modify the `unmodifiable*` methods in `java.util.Collections` to be >> idempotent. That is, when given an immutable collection from >> `java.util.ImmutableCollections` or `java.util.Collections`, these methods >> will return the reference

Integrated: JDK-8261518: jpackage looks for main module in current dir when there is no module-path

2021-03-04 Thread Andy Herrick
On Mon, 1 Mar 2021 15:55:39 GMT, Andy Herrick wrote: > when the app modules have already been jlinked with the runtime, and there is > no need for module-path, jpackage was acting as if the module-path was "." > and picking up jars in the current directory. This pull request has now been

Re: RFR: JDK-8261518: jpackage looks for main module in current dir when there is no module-path [v6]

2021-03-04 Thread Andy Herrick
> when the app modules have already been jlinked with the runtime, and there is > no need for module-path, jpackage was acting as if the module-path was "." > and picking up jars in the current directory. Andy Herrick has updated the pull request incrementally with one additional commit since

Re: RFR: JDK-8261518: jpackage looks for main module in current dir when there is no module-path [v5]

2021-03-04 Thread Alexander Zuev
On Thu, 4 Mar 2021 14:18:59 GMT, Andy Herrick wrote: >> when the app modules have already been jlinked with the runtime, and there >> is no need for module-path, jpackage was acting as if the module-path was >> "." and picking up jars in the current directory. > > Andy Herrick has updated the

Re: RFR: 8262989: Vectorize VectorShuffle checkIndexes, wrapIndexes and laneIsValid methods

2021-03-04 Thread Paul Sandoz
On Thu, 4 Mar 2021 18:45:27 GMT, Sandhya Viswanathan wrote: >> Looks good, a nice incremental improvement. >> >> I suppose `checkIndexes` and `wrapIndexes` could call `laneIsValid`, and >> then call `anyFalse` on the resulting mask. Dunno if that would affect the >> generated code. > >

Re: RFR: 8262989: Vectorize VectorShuffle checkIndexes, wrapIndexes and laneIsValid methods

2021-03-04 Thread Sandhya Viswanathan
On Thu, 4 Mar 2021 16:47:30 GMT, Paul Sandoz wrote: >> The hot path of VectorShuffle checkIndexes, wrapIndexes and laneIsValid >> methods can be implemented using Vector API methods. >> >> For the attached jmh TestSlice.java, performance improves as below. >> >> Before: >> Benchmark

Re: RFR: 8263038: Optimize String.format for simple specifiers

2021-03-04 Thread Claes Redestad
On Thu, 4 Mar 2021 17:20:40 GMT, Claes Redestad wrote: > This patch optimizes String.format expressions that uses trivial specifiers. > In the JDK, the most common variation of String.format is a variation of > format("foo: %s", s), which gets a significant speed-up from this. > > Various

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-03-04 Thread Vladimir Kempik
On Thu, 4 Mar 2021 17:36:22 GMT, Alan Hayward wrote: > I was building this PR on a new machine, and I now get the following error: > > > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31: > > error: cast to smaller integer type

Re: RFR: JDK-8261518: jpackage looks for main module in current dir when there is no module-path [v5]

2021-03-04 Thread Alexey Semenyuk
On Thu, 4 Mar 2021 14:18:59 GMT, Andy Herrick wrote: >> when the app modules have already been jlinked with the runtime, and there >> is no need for module-path, jpackage was acting as if the module-path was >> "." and picking up jars in the current directory. > > Andy Herrick has updated the

RFR: 8263038: Optimize String.format for simple specifiers

2021-03-04 Thread Claes Redestad
This patch optimizes String.format expressions that uses trivial specifiers. In the JDK, the most common variation of String.format is a variation of format("foo: %s", s), which gets a significant speed-up from this. Various other cleanups and minor improvements reduce overhead further and

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-03-04 Thread Alan Hayward
On Thu, 4 Mar 2021 15:27:25 GMT, Gerard Ziemski wrote: >>> A list of the bugs that our internal testing revealed so far: >> >> Are any of these blockers for integration? Some of them are to do with >> things like features that aren't yet supported, and we can't fix what we >> can't see. > >>

Re: RFR: 8262989: Vectorize VectorShuffle checkIndexes, wrapIndexes and laneIsValid methods

2021-03-04 Thread Paul Sandoz
On Wed, 3 Mar 2021 22:32:48 GMT, Sandhya Viswanathan wrote: > The hot path of VectorShuffle checkIndexes, wrapIndexes and laneIsValid > methods can be implemented using Vector API methods. > > For the attached jmh TestSlice.java, performance improves as below. > > Before: > Benchmark

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-03-04 Thread Gerard Ziemski
On Wed, 3 Mar 2021 17:46:41 GMT, Andrew Haley wrote: > > A list of the bugs that our internal testing revealed so far: > > Are any of these blockers for integration? Some of them are to do with things > like features that aren't yet supported, and we can't fix what we can't see. I don't

Re: RFR: 8262300: jpackage app-launcher fails on linux when using JDK11 based runtime

2021-03-04 Thread Andy Herrick
On Thu, 4 Mar 2021 12:32:11 GMT, Alexey Semenyuk wrote: > Fix jpackage app launcher to also look for JLI lib in "lib/jli/libjli.so" > subdirectory of runtime Marked as reviewed by herrick (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2827

Re: RFR: JDK-8261518: jpackage looks for main module in current dir when there is no module-path [v5]

2021-03-04 Thread Andy Herrick
> when the app modules have already been jlinked with the runtime, and there is > no need for module-path, jpackage was acting as if the module-path was "." > and picking up jars in the current directory. Andy Herrick has updated the pull request incrementally with one additional commit since

Re: RFR: 8261845: File permissions of packages built by jpackage

2021-03-04 Thread Andy Herrick
On Thu, 4 Mar 2021 03:59:27 GMT, Alexander Matveev wrote: > - Fixed by adding write permissions to .exe package. Marked as reviewed by herrick (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2822

RFR: 8262300: jpackage app-launcher fails on linux when using JDK11 based runtime

2021-03-04 Thread Alexey Semenyuk
Fix jpackage app launcher to also look for JLI lib in "lib/jli/libjli.so" subdirectory of runtime - Commit messages: - 8262300: jpackage app-launcher fails on linux when using JDK11 based runtime Changes: https://git.openjdk.java.net/jdk/pull/2827/files Webrev:

Re: RFR: 8173970: jar tool should have a way to extract to a directory

2021-03-04 Thread Lance Andersen
Hi Jaikiran From https://docs.oracle.com/en/java/javase/15/docs/specs/man/jar.html The jar man page includes the following : The syntax for the jar command resembles the syntax for the tar command. Because of the above, I feel that we should support: ——— -C —dir —directory The addition

Re: RFR: 8261845: File permissions of packages built by jpackage

2021-03-04 Thread Alan Bateman
On Thu, 4 Mar 2021 03:59:27 GMT, Alexander Matveev wrote: > - Fixed by adding write permissions to .exe package. src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinExeBundler.java line 144: > 142: Files.copy(exePath, dstExePath); > 143: > 144: