Re: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor specifiers [v18]

> @cl4es made performance optimizations for the simple specifiers of > String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the > same idea, I continued to make improvements. I made patterns like %2d %02d > also be optimized. > > The following are the test results based on

Re: RFR: 8317742: ISO Starndard Date Format implementation consistency on DateTimeFormatter and String.format [v2]

> j.u.Formatter now prints "%tF" (iso standard date) and the result is > incorrect when processing year < 0 or year > 温绍锦 has updated the pull request incrementally with one additional commit since the last revision: No longer localize printed numbers - Changes: - all:

Integrated: JDK-8317633: Modernize text.testlib.HexDumpReader

On Fri, 6 Oct 2023 17:19:29 GMT, Justin Lu wrote: > Please review this PR which cleans up the static test utility class > _HexDumpReader_. > > This cleans up the code by replacing the nested _ByteArrayBuilder_ class with > _HexFormat_, and simplifies the File processing by using a stream.

Re: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor specifiers [v17]

On Mon, 9 Oct 2023 20:40:43 GMT, 温绍锦 wrote: >> @cl4es made performance optimizations for the simple specifiers of >> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the >> same idea, I continued to make improvements. I made patterns like %2d %02d >> also be optimized.

Re: RFR: JDK-8317372: Refactor some NumberFormat tests to use JUnit

On Tue, 3 Oct 2023 22:23:11 GMT, Justin Lu wrote: > Please review this PR which refactors a number of tests under > `test/text/NumberFormat` to use JUnit. > > During the switch to JUnit, the tests had the following updates (to improve > readability) > - separate the test data generation from

Integrated: JDK-8317631: Refactor ChoiceFormat tests to use JUnit

On Thu, 5 Oct 2023 20:57:07 GMT, Justin Lu wrote: > Please review this PR which refactors the ChoiceFormat tests to use JUnit. This pull request has now been integrated. Changeset: 5e8d893c Author:Justin Lu URL:

Re: RFR: 8317742: ISO Starndard Date Format implementation consistency on DateTimeFormatter and String.format

On Tue, 3 Oct 2023 21:37:46 GMT, 温绍锦 wrote: > j.u.Formatter now prints "%tF" (iso standard date) and the result is > incorrect when processing year < 0 or year > When String.format handles "%tF" Specifier, it uses the same behavior as DateTimeFormatter. This will cause the value of

Re: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v15]

> This is the first draft of a patch for Primitive types in patterns, > instanceof, and switch (Preview). > > Draft spec here: > https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html Aggelos Biboudis has updated the pull request incrementally with one

Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v42]

On Mon, 9 Oct 2023 18:15:12 GMT, Paul Sandoz wrote: > > _Mailing list message from [Florian Weimer](mailto:f...@deneb.enyo.de) on > > [hotspot-runtime-dev](mailto:hotspot-runtime-...@mail.openjdk.org):_ > > I believe this has introduced a build failure with GCC 12.2 on Debian 12.1: > > I

Re: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor specifiers [v17]

> @cl4es made performance optimizations for the simple specifiers of > String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the > same idea, I continued to make improvements. I made patterns like %2d %02d > also be optimized. > > The following are the test results based on

Re: RFR: 8315585: Optimization for decimal to string [v2]

On Mon, 9 Oct 2023 19:20:29 GMT, 温绍锦 wrote: >> I submitted PR #1 before, and there were too many changes. I split it >> into multiple PRs with small changes. This one is one of them. >> >> this PR removed the duplicate code for getChars in >> BigDecimal#StringBuilderHelper, i also make

Re: RFR: 8317742: ISO Starndard Date Format implementation consistency on DateTimeFormatter and String.format

On Tue, 3 Oct 2023 21:37:46 GMT, 温绍锦 wrote: > j.u.Formatter now prints "%tF" (iso standard date) and the result is > incorrect when processing year < 0 or year > The CSR is created, if you can provide (as a comment on the PR) the descriptions as described in the template, I can put them

Re: RFR: 8317742: ISO Starndard Date Format implementation consistency on DateTimeFormatter and String.format

On Tue, 3 Oct 2023 21:37:46 GMT, 温绍锦 wrote: > j.u.Formatter now prints "%tF" (iso standard date) and the result is > incorrect when processing year < 0 or year > This PR will need an evaluation of the compatibility risk of changing the behavior, describing existing uses and scope and how

Re: 回复：Adding appendHex method to StringBuilder

Hi, The j.u.HexFormat class has methods that append hex formatted byte arrays to an Appendable such as StringBuilder. The `toHexDigits` methods return strings with the hex values of byte, short, char, int, and long. Similar `formatHex` methods could be added with an Appendable argument

Re: RFR: JDK-8317633: Modernize text.testlib.HexDumpReader [v2]

On Fri, 6 Oct 2023 21:07:51 GMT, Justin Lu wrote: >> Please review this PR which cleans up the static test utility class >> _HexDumpReader_. >> >> This cleans up the code by replacing the nested _ByteArrayBuilder_ class >> with _HexFormat_, and simplifies the File processing by using a

Re: RFR: 8315585: Optimization for decimal to string [v2]

> I submitted PR #1 before, and there were too many changes. I split it > into multiple PRs with small changes. This one is one of them. > > this PR removed the duplicate code for getChars in > BigDecimal#StringBuilderHelper, i also make performance faster, Here are the > numbers run on a

Re: RFR: 8317742: ISO Starndard Date Format implementation consistency on DateTimeFormatter and String.format

On Wed, 4 Oct 2023 11:33:16 GMT, Claes Redestad wrote: > I think this deserves a discussion on the mailing list before jumping to a > PR, as neither `%tF` nor the ISO-8601 standard it defers to is particularly > well-defined outside of the range 0- Thank you @cl4es for your suggestion, I

Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v42]

On Sun, 8 Oct 2023 06:18:13 GMT, Danny Thomas wrote: > A [discussion on > Reddit](https://www.reddit.com/r/java/comments/171t5sj/heads_up_openjdk_implementation_of_avx512_based/) > raised that this had the potential to regress sort performance on AMD Zen 4. > The poster didn't have access to

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v5]

> Limit native memory allocation and move write loop from the native layer into > Java. This change should make the OOME reported in the issue much less likely. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the

Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v42]

On Thu, 5 Oct 2023 23:36:48 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX512 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >>

RFR: 8317742: ISO Starndard Date Format implementation consistency on DateTimeFormatter and String.format

j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > - Commit messages: - fix format ""%tF" (iso standard date) not correct Changes: https://git.openjdk.org/jdk/pull/16033/files Webrev:

Re: RFR: 8317742: ISO Starndard Date Format implementation consistency on DateTimeFormatter and String.format

On Tue, 3 Oct 2023 21:37:46 GMT, 温绍锦 wrote: > j.u.Formatter now prints "%tF" (iso standard date) and the result is > incorrect when processing year < 0 or year > I think this deserves a discussion on the mailing list before jumping to a PR, as neither `%tF` nor the ISO-8601 standard it

Re: RFR: 8317742: ISO Starndard Date Format implementation consistency on DateTimeFormatter and String.format

On Tue, 3 Oct 2023 21:37:46 GMT, 温绍锦 wrote: > j.u.Formatter now prints "%tF" (iso standard date) and the result is > incorrect when processing year < 0 or year > @cl4es could you please review my code? Thank you! - PR Comment:

Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v42]

On Thu, 5 Oct 2023 23:36:48 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX512 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >>

Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v42]

On Sun, 8 Oct 2023 06:18:13 GMT, Danny Thomas wrote: >> Srinivas Vamsi Parasa has updated the pull request with a new target base >> due to a merge or a rebase. The pull request now contains 45 commits: >> >> - fix code style and formatting >> - Merge branch 'master' of

Re: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v14]

> This is the first draft of a patch for Primitive types in patterns, > instanceof, and switch (Preview). > > Draft spec here: > https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html Aggelos Biboudis has updated the pull request incrementally with five

Integrated: 8317471: ListFormat::parseObject() spec can be improved on parsePosition valid values

On Thu, 5 Oct 2023 17:57:00 GMT, Naoto Sato wrote: > Adding IOOBE clause to clarify the behavior on an invalid `parsePos` argument > on calling `ListFormat::parseObject()`. A corresponding CSR has also been > drafted. This pull request has now been integrated. Changeset: 1f063251 Author:

Re: ISO Starndard Date Format implementation consistency on DateTimeFormatter and String.format

Hi, Java.time has a clear definition of negative years. It would need a closer look as to j.u.Formatter's interpretation of negative years, though it should be consistent for j.t.LocalDate. Created: 8317742 ISO Starndard Date Format

Re: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails intermittent on AIX in TreeTest.test5 [v2]

On Mon, 9 Oct 2023 15:15:52 GMT, Joachim Kern wrote: > Previously the implementation based on the /proc file system lead to double > pids in the child list; at least intermittent. Using the API getprocs64() > instead I was able to eliminate those double pids (and increase the > performance by

Re: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails intermittent on AIX in TreeTest.test5 [v2]

On Mon, 9 Oct 2023 15:00:18 GMT, Joachim Kern wrote: >> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX >> in TreeTest.test5. >> >> test TreeTest.test5(): failure >> java.lang.AssertionError: expected direct children expected [2] but found [3] >> at

Re: RFR: 8308753: Class-File API transition to Preview [v17]

> Classfile API is an internal library under package `jdk.internal.classfile`  > in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it > into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR

Re: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails intermittent on AIX in TreeTest.test5 [v2]

On Mon, 9 Oct 2023 15:00:18 GMT, Joachim Kern wrote: >> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX >> in TreeTest.test5. >> >> test TreeTest.test5(): failure >> java.lang.AssertionError: expected direct children expected [2] but found [3] >> at

Re: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails intermittent on AIX in TreeTest.test5 [v2]

> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX > in TreeTest.test5. > > test TreeTest.test5(): failure > java.lang.AssertionError: expected direct children expected [2] but found [3] > at org.testng.Assert.fail(Assert.java:99) > at

Re: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor specifiers [v16]

On Thu, 5 Oct 2023 20:02:44 GMT, 温绍锦 wrote: >> @cl4es made performance optimizations for the simple specifiers of >> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the >> same idea, I continued to make improvements. I made patterns like %2d %02d >> also be optimized.

Re: RFR: JDK-8077371: Binary files in JAXP test should be removed [v8]

> Test is updated to create the binary files during test execution. Mahendra Chhipa 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 10 additional

Re: RFR: 8308753: Class-File API transition to Preview [v16]

> Classfile API is an internal library under package `jdk.internal.classfile`  > in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it > into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR

Re: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails intermittent on AIX in TreeTest.test5

On Thu, 5 Oct 2023 10:02:05 GMT, Joachim Kern wrote: > We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX > in TreeTest.test5. > > test TreeTest.test5(): failure > java.lang.AssertionError: expected direct children expected [2] but found [3] > at