Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v4]

2021-05-03 Thread Alexander Matveev
On Mon, 3 May 2021 22:52:21 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via >> hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable >> on x64 without specifying hostArchitectures which is not correct and if >> install on a

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v4]

2021-05-03 Thread Kevin Rushforth
On Mon, 3 May 2021 22:52:21 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via >> hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable >> on x64 without specifying hostArchitectures which is not correct and if >> install on a

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v4]

2021-05-03 Thread Alexey Semenyuk
On Mon, 3 May 2021 22:52:21 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via >> hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable >> on x64 without specifying hostArchitectures which is not correct and if >> install on a

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v4]

2021-05-03 Thread Alexander Matveev
> jpackage should specify architecture for produced PKG files via > hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable > on x64 without specifying hostArchitectures which is not correct and if > install on arm Mac it will request Rosetta 2. With proposed fix by setting

Re: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2]

2021-05-03 Thread Sandhya Viswanathan
On Mon, 3 May 2021 21:41:26 GMT, Paul Sandoz wrote: >> Sandhya Viswanathan has updated the pull request with a new target base due >> to a merge or a rebase. The pull request now contains six commits: >> >> - Merge master >> - remove whitespace >> - Merge master >> - Small fix >> - cleanup

Integrated: JDK-8266391: Replace use of reflection in jdk.internal.platform.Metrics

2021-05-03 Thread Mandy Chung
On Fri, 30 Apr 2021 22:39:46 GMT, Mandy Chung wrote: > Replace the use of reflection with a direct method call to a > platform-specific implementation class where `SystemMetrics::instance` > returns `CgroupMetrics.getInstance()` on linux and returns null on other > platforms. This pull reques

Re: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2]

2021-05-03 Thread Paul Sandoz
On Wed, 28 Apr 2021 21:11:26 GMT, Sandhya Viswanathan wrote: >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 >> assembly provide optimized implementation for Vector API transcendental and >> trigonometric methods. >> These methods are built into a separate library inst

RFR: 8264777: Overload optimized FileInputStream::readAllBytes

2021-05-03 Thread Brian Burkhalter
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 composing the

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v3]

2021-05-03 Thread Alexey Semenyuk
On Mon, 3 May 2021 19:26:19 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via >> hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable >> on x64 without specifying hostArchitectures which is not correct and if >> install on a

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v3]

2021-05-03 Thread Alexey Semenyuk
On Mon, 3 May 2021 20:20:52 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8266179: [macos] jpackage should specify architecture for produced pkg >> files [v3] > > test/jdk/tools/jpackag

Re: RFR: JDK-8266391: Replace use of reflection in jdk.internal.platform.Metrics

2021-05-03 Thread Claes Redestad
On Fri, 30 Apr 2021 22:39:46 GMT, Mandy Chung wrote: > Replace the use of reflection with a direct method call to a > platform-specific implementation class where `SystemMetrics::instance` > returns `CgroupMetrics.getInstance()` on linux and returns null on other > platforms. Looks good to me

Re: RFR: JDK-8266227: Fix help text for --mac-signing-keychain

2021-05-03 Thread Alexey Semenyuk
On Fri, 30 Apr 2021 15:25:13 GMT, Andy Herrick wrote: > JDK-8266227: Fix help text for --mac-signing-keychain Marked as reviewed by asemenyuk (Reviewer). The changes seems to be covering more than what the title of the CR states. Would it make sense to update the title accordingly? --

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v3]

2021-05-03 Thread Alexander Matveev
> jpackage should specify architecture for produced PKG files via > hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable > on x64 without specifying hostArchitectures which is not correct and if > install on arm Mac it will request Rosetta 2. With proposed fix by setting

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v2]

2021-05-03 Thread Alexey Semenyuk
On Mon, 3 May 2021 17:30:15 GMT, Alexander Matveev wrote: >> test/jdk/tools/jpackage/macosx/HostArchPkgTest.java line 57: >> >>> 55: Path distributionFile = cmd.unpackedPackageDirectory() >>> 56: .toAbsolutePath() >>> 57: .getParent() >> >> Why .getParent

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v2]

2021-05-03 Thread Alexey Semenyuk
On Mon, 3 May 2021 17:24:16 GMT, Alexander Matveev wrote: >> test/jdk/tools/jpackage/macosx/HostArchPkgTest.java line 84: >> >>> 82: } >>> 83: >>> 84: public static void main(String[] args) throws Exception { >> >> Please don't use direct TKit.run() call. Use >> jdk.jpackage.test.Anno

RFR: JDK-8266391: Replace use of reflection in jdk.internal.platform.Metrics

2021-05-03 Thread Mandy Chung
Replace the use of reflection with a direct method call to a platform-specific implementation class where `SystemMetrics::instance` returns `CgroupMetrics.getInstance()` on linux and returns null on other platforms. - Commit messages: - fix whitespace - JDK-8266391: Replace use of

Re: RFR: 8265989: System property for the native character encoding name [v3]

2021-05-03 Thread Roger Riggs
On Fri, 30 Apr 2021 22:10:21 GMT, Naoto Sato wrote: >> After some internal discussion, we thought it was good to expose the native >> environment's default character encoding, which Charset.defaultCharset() is >> currently based on. This way applications will have a better migration path >> af

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v2]

2021-05-03 Thread Alexander Matveev
On Mon, 3 May 2021 16:01:36 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8266179: [macos] jpackage should specify architecture for produced pkg >> files [v2] > > test/jdk/tools/jpackag

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v2]

2021-05-03 Thread Alexander Matveev
On Mon, 3 May 2021 15:58:56 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8266179: [macos] jpackage should specify architecture for produced pkg >> files [v2] > > test/jdk/tools/jpackag

Re: RFR: 8265989: System property for the native character encoding name [v3]

2021-05-03 Thread Iris Clark
On Fri, 30 Apr 2021 22:10:21 GMT, Naoto Sato wrote: >> After some internal discussion, we thought it was good to expose the native >> environment's default character encoding, which Charset.defaultCharset() is >> currently based on. This way applications will have a better migration path >> af

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

2021-05-03 Thread Paul Sandoz
On Mon, 3 May 2021 06:51:29 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 = lane

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

2021-05-03 Thread Sandhya Viswanathan
On Fri, 30 Apr 2021 01:58:27 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/uns

Re: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v6]

2021-05-03 Thread Jan Lahoda
On Sun, 2 May 2021 02:10:26 GMT, Vicente Romero wrote: >> Please review this PR that intents to make sealed classes a final feature in >> Java. This PR contains compiler and VM changes. In line with similar PRs, >> which has made preview features final, this one is mostly removing preview >> r

Re: RFR: 8260621: Avoid memory leak in ImageBufferCache [v2]

2021-05-03 Thread Jim Laskey
On Wed, 3 Feb 2021 01:29:02 GMT, Bo Zhang wrote: >> Previously, `ImageBufferCache` contains a ThreadLocal field which holds >> strong reference to `ImageBufferCache$BufferReference.class`. When loaded >> from `jrt-fs.jar`, this will keep `JrtFileSystemProvider$JrtFsLoader` >> in memory forever a

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v2]

2021-05-03 Thread Alexey Semenyuk
On Sat, 1 May 2021 04:04:17 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via >> hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable >> on x64 without specifying hostArchitectures which is not correct and if >> install on a

Re: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native

2021-05-03 Thread Jorn Vernee
On Mon, 26 Apr 2021 14:30:17 GMT, Maurizio Cimadamore wrote: >> macOS on Apple silicon uses slightly different ABI conventions to the >> standard AArch64 ABI. The differences are outlined in [1]. In >> particular in the standard (AAPCS) ABI, variadic arguments may be passed >> in either regist

Re: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native

2021-05-03 Thread Jorn Vernee
On Mon, 3 May 2021 15:31:53 GMT, Jorn Vernee wrote: >> macOS on Apple silicon uses slightly different ABI conventions to the >> standard AArch64 ABI. The differences are outlined in [1]. In >> particular in the standard (AAPCS) ABI, variadic arguments may be passed >> in either registers or on

Re: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native

2021-05-03 Thread Jorn Vernee
On Thu, 22 Apr 2021 08:19:53 GMT, Nick Gasson wrote: > macOS on Apple silicon uses slightly different ABI conventions to the > standard AArch64 ABI. The differences are outlined in [1]. In > particular in the standard (AAPCS) ABI, variadic arguments may be passed > in either registers or on the

Re: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native

2021-05-03 Thread Jorn Vernee
On Tue, 27 Apr 2021 02:14:07 GMT, Nick Gasson wrote: >> How about StandardAArch64Linker? Otherwise MacOsAArch64Linker sounds like it >> should be a specialisation of AArch64Linker. > > Or LinuxAArch64Linker if we're going to rename the CABI enum AArch64 -> > LinuxAArch64? But this would also be

Re: RFR: 8266179: [macos] jpackage should specify architecture for produced pkg files [v2]

2021-05-03 Thread Alexey Semenyuk
On Sat, 1 May 2021 04:04:17 GMT, Alexander Matveev wrote: >> jpackage should specify architecture for produced PKG files via >> hostArchitectures="x86_x64 or arm64". aarch64 installer will be installable >> on x64 without specifying hostArchitectures which is not correct and if >> install on a

Re: RFR: 8265248: Implementation Specific Properties: change prefix, plus add existing properties [v3]

2021-05-03 Thread Roger Riggs
On Wed, 28 Apr 2021 18:22:27 GMT, Joe Wang wrote: >> Update module summary, add a few existing properties and features into the >> tables. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revision: > > replace isAssignableFrom with instanceo

Re: RFR: 8203359: Container level resources events [v11]

2021-05-03 Thread Jaroslav Bachorik
> With this change it becomes possible to surface various cgroup level metrics > (available via `jdk.internal.platform.Metrics`) as JFR events. > > Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is > turned into JFR events to start with. > * CPU related metrics > * Memor

Re: RFR: 8203359: Container level resources events [v10]

2021-05-03 Thread Jaroslav Bachorik
On Tue, 27 Apr 2021 09:40:01 GMT, Severin Gehwolf wrote: >> Jaroslav Bachorik has updated the pull request with a new target base due to >> a merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains 13 additional >> c

Re: RFR: 8203359: Container level resources events [v10]

2021-05-03 Thread Jaroslav Bachorik
On Mon, 26 Apr 2021 21:20:57 GMT, Erik Gahlin wrote: >> Jaroslav Bachorik has updated the pull request with a new target base due to >> a merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains 13 additional >> commi