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

2021-04-29 Thread Joe Wang
On Wed, 28 Apr 2021 22:24:31 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 > after

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

2021-04-29 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 hostArch

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

2021-04-29 Thread Paul Sandoz
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: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v6]

2021-04-29 Thread Yi Yang
> The JDK codebase re-created many variants of checkIndex(`grep -I -r > 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which > annotated with @IntrinsicCandidate and it only has a corresponding C1 > intrinsic version. > > In fact, there is an utility method > `jdk.intern

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

2021-04-29 Thread Sandhya Viswanathan
> 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 library_call.cpp:inli

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

2021-04-29 Thread Sandhya Viswanathan
On Fri, 30 Apr 2021 00:17:24 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: 8265128: [REDO] Optimize Vector API slice and unslice operations [v2]

2021-04-29 Thread Paul Sandoz
On Thu, 29 Apr 2021 23:36:22 GMT, Sandhya Viswanathan wrote: >> test/jdk/jdk/incubator/vector/AbstractVectorConversionTest.java line 51: >> >>> 49: } >>> 50: >>> 51: static final int INVOC_COUNT = >>> Integer.getInteger("jdk.incubator.vector.test.loop-iterations", 100); >> >> Why did

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

2021-04-29 Thread Paul Sandoz
On Fri, 30 Apr 2021 00:17:24 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: 8265128: [REDO] Optimize Vector API slice and unslice operations

2021-04-29 Thread Sandhya Viswanathan
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 u

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

2021-04-29 Thread Sandhya Viswanathan
> 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 library_call.cpp:inli

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

2021-04-29 Thread Sandhya Viswanathan
On Thu, 29 Apr 2021 22:59:13 GMT, Paul Sandoz 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 usin

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

2021-04-29 Thread Paul Sandoz
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 u

Re: RFR: 8265137: java.util.Random suddenly has new public methods nowhere documented [v7]

2021-04-29 Thread Uwe Schindler
On Tue, 27 Apr 2021 10:50:51 GMT, Jim Laskey wrote: >> Move makeXXXSpilterator from public (@hidden) to protected. No API ch > > Jim Laskey has updated the pull request incrementally with one additional > commit since the last revision: > > Remove unnecessary constructor. Marked as reviewed

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

2021-04-29 Thread Sandhya Viswanathan
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 library_call.cpp:inline_preconditio

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

2021-04-29 Thread Mandy Chung
On Thu, 29 Apr 2021 10:31:29 GMT, Maurizio Cimadamore wrote: > I think I expect that, with caller sensitive, it is possible from a client in > an "enabled" module to obtain a MethodHandle, and then pass it to an > unprivileged module, which then calls it, and works ok. This matches my > expec

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

2021-04-29 Thread Joe Wang
On Thu, 29 Apr 2021 13:39:58 GMT, Roger Riggs wrote: >> Thanks, Joe and Iris. I agree with Iris and that's the reason I chose the >> description. System properties are inherently mutable. There are some >> "protected" ones, by that I mean a private copy is made just after >> initialization for

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

2021-04-29 Thread Naoto Sato
On Wed, 28 Apr 2021 22:24:31 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 > after

Integrated: 8266078: Reader.read(CharBuffer) advances Reader position for read-only Charbuffers

2021-04-29 Thread Brian Burkhalter
On Tue, 27 Apr 2021 18:47:41 GMT, Brian Burkhalter wrote: > Please consider this request to modify `Reader.read(CharBuffer)` to check > whether the buffer is read-only before reading any characters from the > character stream. This can happen now if the buffer is read-only. Character > are fir

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

2021-04-29 Thread Jaikiran Pai
On Thu, 1 Apr 2021 15:02:42 GMT, Jaikiran Pai wrote: >> Can I please get a review for this patch which proposes to implement the >> enhancement request noted in >> https://bugs.openjdk.java.net/browse/JDK-8173970? >> >> The commit in this PR introduces the `-o` and `--output-dir` option to the

Integrated: 8266014: Regression brought by optimization done with JDK-4926314

2021-04-29 Thread Brian Burkhalter
On Tue, 27 Apr 2021 01:26:53 GMT, Brian Burkhalter wrote: > Please consider this request to correct a minor problem with the optimization > added for JDK-4926314. The change is to attempt to read the number of > elements remaining in the target buffer unless that number is non-positive in > wh

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

2021-04-29 Thread Alan Bateman
On Thu, 29 Apr 2021 14:12:29 GMT, Maurizio Cimadamore wrote: > Naive question: any reason as to why we're not providing a new static API > method in Charset to return the platform encoder? This initially will return > same thing as Charset.defaultEncoder - but as JEP 400 is delivered the two

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

2021-04-29 Thread Maurizio Cimadamore
On Thu, 29 Apr 2021 14:08:36 GMT, Maurizio Cimadamore wrote: > Naive question: any reason as to why we're not providing a new static API > method in Charset to return the platform encoder? This initially will return > same thing as Charset.defaultEncoder - but as JEP 400 is delivered the two

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

2021-04-29 Thread Maurizio Cimadamore
On Wed, 28 Apr 2021 22:24:31 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 > after

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

2021-04-29 Thread Naoto Sato
On Thu, 29 Apr 2021 13:23:42 GMT, Alan Bateman wrote: >> `native.encoding` preserves the encoding that current >> `Charset.defaultCharset()` is returning, which is based on `file.encoding`. >> So I believe the current implementation is correct. If it is biased toward >> `sun.jnu.encoding`, it

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

2021-04-29 Thread Roger Riggs
On Thu, 29 Apr 2021 13:06:35 GMT, Naoto Sato wrote: >> I suspect that if setProperty("native.encoding", "foo") succeeds, then it >> will return "foo". I also believe that a later invocation of >> getProperty("native.encoding") will also return "foo". If that's the case, >> then I don't thin

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

2021-04-29 Thread Alan Bateman
On Thu, 29 Apr 2021 13:11:53 GMT, Naoto Sato wrote: >> src/java.base/share/classes/jdk/internal/util/SystemProps.java line 69: >> >>> 67: ? raw.propDefault(Raw._sun_jnu_encoding_NDX) >>> 68: : raw.propDefault(Raw._file_encoding_NDX)); >>> 69: put(props, "n

RFR: 8266168: -Wmaybe-uninitialized happens in check_code.c

2021-04-29 Thread Yasumasa Suenaga
We can see following compiler warning in check_code.c on GCC 11. - Commit messages: - 8266168: -Wmaybe-uninitialized happens in check_code.c Changes: https://git.openjdk.java.net/jdk/pull/3787/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3787&range=00 Issue: https:

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

2021-04-29 Thread Naoto Sato
On Thu, 29 Apr 2021 07:17:26 GMT, Alan Bateman 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 >>

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

2021-04-29 Thread Naoto Sato
On Thu, 29 Apr 2021 05:38:21 GMT, Iris Clark wrote: >> src/java.base/share/classes/java/lang/System.java line 704: >> >>> 702: * {@systemProperty native.encoding} >>> 703: * Character encoding name derived from the host >>> environment and/or >>> 704: * the user's setting

Integrated: 8265918: java/io/Console/CharsetTest.java failed with "expect: spawn id exp6 not open"

2021-04-29 Thread Naoto Sato
On Wed, 28 Apr 2021 16:58:50 GMT, Naoto Sato wrote: > This new regression test was introduced with the Console::charset(), but it > fails on ubuntu platforms assuming its locales/encoding incorrectly. To not > make false-alarm/noise on test runs, this fix minimizes the tests not > depending on

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

2021-04-29 Thread Maurizio Cimadamore
> 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 request

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

2021-04-29 Thread Maurizio Cimadamore
On Wed, 28 Apr 2021 18:33:36 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] - https://openjd

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

2021-04-29 Thread Maurizio Cimadamore
> 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 request

Re: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v5]

2021-04-29 Thread Yi Yang
On Thu, 29 Apr 2021 10:13:05 GMT, Daniel Fuchs wrote: >> Yi Yang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> AssertionError when expected exception was not thrown > > test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line

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

2021-04-29 Thread Maurizio Cimadamore
On Wed, 28 Apr 2021 23:22:38 GMT, Mandy Chung wrote: > My statement was overly simplified, sorry. If `handle` is invoked in another > module B and invoked by a class in module B, which module (the `lookup`'s > module or ) do you expect be the caller to check against for native access > check?

Re: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v5]

2021-04-29 Thread Daniel Fuchs
On Thu, 29 Apr 2021 10:13:16 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r >> 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which >> annotated with @IntrinsicCandidate and it only has a corresponding C1 >> intrinsic version.

Re: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v5]

2021-04-29 Thread Yi Yang
> The JDK codebase re-created many variants of checkIndex(`grep -I -r > 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which > annotated with @IntrinsicCandidate and it only has a corresponding C1 > intrinsic version. > > In fact, there is an utility method > `jdk.intern

Re: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v4]

2021-04-29 Thread Yi Yang
On Thu, 29 Apr 2021 09:30:50 GMT, Daniel Fuchs wrote: >> Yi Yang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> remove extra newline > > test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 60: > >> 58: } catch (I

Re: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v4]

2021-04-29 Thread Daniel Fuchs
On Thu, 29 Apr 2021 02:53:18 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r >> 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which >> annotated with @IntrinsicCandidate and it only has a corresponding C1 >> intrinsic version.

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

2021-04-29 Thread Alan Bateman
On Wed, 28 Apr 2021 22:24:31 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 > after