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
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
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
> 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
>
> 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
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
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
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
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
> 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
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
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
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
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
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
>
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
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
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
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
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
>
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
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
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
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
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
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,
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=3787=00
Issue:
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
>>
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
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
> 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
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] -
> 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
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
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?
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.
> 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
>
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
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.
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
40 matches
Mail list logo
