From duke at openjdk.org  Mon Jul  1 01:48:52 2024
From: duke at openjdk.org (lingjun-cg)
Date: Mon, 1 Jul 2024 01:48:52 GMT
Subject: <i18n dev> RFR: 8333396: Performance regression of
 DecimalFormat.format [v15]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <Xj5N_ethenooDC7OyjA8lT9SC0hajU8HNlQpB2EhmN4=.fa82acd2-0543-4ba2-b6a1-174b2f7ebadb@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Performance regression of DecimalFormat.format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/b5bdc733..da09d85a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=13-14

  Stats: 9 lines in 3 files changed: 0 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From liach at openjdk.org  Mon Jul  1 06:21:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 1 Jul 2024 06:21:22 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v9]
In-Reply-To: <nyDJf6K1LNCL1aB8If7oSzVFGVAqtsD_E7dUM9OCCSI=.f90dacd7-d5b2-4f46-9d4b-0f05864ba1e3@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <nyDJf6K1LNCL1aB8If7oSzVFGVAqtsD_E7dUM9OCCSI=.f90dacd7-d5b2-4f46-9d4b-0f05864ba1e3@github.com>
Message-ID: <M6C8nDxXEaFpBmqzzp6qMEUyBI9BZfk2t0nVfBA6kaQ=.b1a69725-6bc2-4d68-9917-b8782823d4dd@github.com>

On Sun, 30 Jun 2024 18:21:52 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
>> 
>> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
>> 
>> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
>> 
>> Below is a comparison of String.format and concat-based and StringBuilder:
>> 
>> * benchmark java code
>> 
>> public class StringFormat {
>>     @Benchmark
>>     public String stringIntFormat() {
>>         return "%s %d".formatted(s, i);
>>     }
>> 
>>     @Benchmark
>>     public String stringIntConcat() {
>>         return s + " " + i;
>>     }
>> 
>>     @Benchmark
>>     public String stringIntStringBuilder() {
>>         return new StringBuilder(s).append(" ").append(i).toString();
>>     }
>> }
>> 
>> 
>> * benchmark number on macbook m1 pro
>> 
>> Benchmark                            Mode  Cnt   Score   Error  Units
>> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
>> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
>> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
>> 
>> 
>> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
>> 
>> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
>> 
>> d
>> x
>> X
>> s
>> 
>> If necessary, we can add a few more.
>> 
>> 
>> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
>> 
>> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
>> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
>> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
>> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
>> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
>> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
>> 
>> +Benchmark                ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code style

As promising as the performance number is, I think we need to ensure two things:
1. Correctness: this patch adds a lot of special cases; not sure if the current test cases already cover all of them. In addition, format is i18n stuff, which will need extra review besides the review for performance gains.
2. Validity: the existing benchmarks don't have profile pollution: see `ReflectionSpeedBenchmark` https://github.com/openjdk/jdk/blob/d9bcf061450ebfb7fe02b5a50c855db1d9178e5d/test/micro/org/openjdk/bench/java/lang/reflect/ReflectionSpeedBenchmark.java#L291 where the `Method.invoke` and `Constructor.newInstance` are called to tamper JIT's profiling, as JIT can conclude that only one format shape is ever used in your benchmark, which is unlikely in production. You should call `String.format` and `String.formatted` with varied format strings and arguments in setup for profile pollution.<br>
  An extreme example would be at https://github.com/openjdk/jdk/pull/14944#issuecomment-1644050455, where `Arrays.hashCode(Object[])` where every element is an `Integer` is extremely fast, but slows down drastically once different arrays are passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2199327844

From redestad at openjdk.org  Mon Jul  1 07:55:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 1 Jul 2024 07:55:20 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v9]
In-Reply-To: <M6C8nDxXEaFpBmqzzp6qMEUyBI9BZfk2t0nVfBA6kaQ=.b1a69725-6bc2-4d68-9917-b8782823d4dd@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <nyDJf6K1LNCL1aB8If7oSzVFGVAqtsD_E7dUM9OCCSI=.f90dacd7-d5b2-4f46-9d4b-0f05864ba1e3@github.com>
 <M6C8nDxXEaFpBmqzzp6qMEUyBI9BZfk2t0nVfBA6kaQ=.b1a69725-6bc2-4d68-9917-b8782823d4dd@github.com>
Message-ID: <kPMDSKB3gvi102TV-gAkfjXY0YEji6hz7f_jPCrVR0I=.6529323f-ff27-407f-b019-bce688478e6d@github.com>

On Mon, 1 Jul 2024 06:18:55 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code style
>
> As promising as the performance number is, I think we need to ensure two things:
> 1. Correctness: this patch adds a lot of special cases; not sure if the current test cases already cover all of them. In addition, format is i18n stuff, which will need extra review besides the review for performance gains.
> 2. Validity: the existing benchmarks don't have profile pollution: see `ReflectionSpeedBenchmark` https://github.com/openjdk/jdk/blob/d9bcf061450ebfb7fe02b5a50c855db1d9178e5d/test/micro/org/openjdk/bench/java/lang/reflect/ReflectionSpeedBenchmark.java#L291 where the `Method.invoke` and `Constructor.newInstance` are called to tamper JIT's profiling, as JIT can conclude that only one format shape is ever used in your benchmark, which is unlikely in production. You should call `String.format` and `String.formatted` with varied format strings and arguments in setup for profile pollution.<br>
>   An extreme example would be at https://github.com/openjdk/jdk/pull/14944#issuecomment-1644050455, where `Arrays.hashCode(Object[])` where every element is an `Integer` is extremely fast, but slows down drastically once different arrays are passed.

Fully agree with the points @liach made above that this needs to be scrutinized for correctness and validity. For example we need to better explore cases where detection for the fast path might be costlier, for example a longer format string with or without some acceptable specifiers early, then something that forces us into the slow path only at the end.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2199478317

From duke at openjdk.org  Mon Jul  1 12:07:01 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 1 Jul 2024 12:07:01 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v10]
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <CwP_a8lnhskESg64JGFg2zMNMhnRAIX05kD9F9gcgxY=.300ea936-ff2b-45fd-aa22-d2922d0d242f@github.com>

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add StringFormat test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19956/files
  - new: https://git.openjdk.org/jdk/pull/19956/files/9b2bb485..7e651817

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=08-09

  Stats: 303 lines in 1 file changed: 303 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956

PR: https://git.openjdk.org/jdk/pull/19956

From duke at openjdk.org  Mon Jul  1 12:53:42 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 1 Jul 2024 12:53:42 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v11]
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <U5SXpaElhORxVv1wGuooCK3E6tvcecDtFGu8QDJstXo=.0560abeb-dcbf-4772-bdf3-f34f3d655abe@github.com>

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add more test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19956/files
  - new: https://git.openjdk.org/jdk/pull/19956/files/7e651817..905012af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=09-10

  Stats: 50 lines in 1 file changed: 48 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956

PR: https://git.openjdk.org/jdk/pull/19956

From duke at openjdk.org  Mon Jul  1 12:57:21 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 1 Jul 2024 12:57:21 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v11]
In-Reply-To: <U5SXpaElhORxVv1wGuooCK3E6tvcecDtFGu8QDJstXo=.0560abeb-dcbf-4772-bdf3-f34f3d655abe@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <U5SXpaElhORxVv1wGuooCK3E6tvcecDtFGu8QDJstXo=.0560abeb-dcbf-4772-bdf3-f34f3d655abe@github.com>
Message-ID: <AP4F_lNEQIkS5UG0zGM-hIMvqApKPAG1Nlw0OfMASms=.fa777123-b2a5-4528-aa0a-7714663b7c0b@github.com>

On Mon, 1 Jul 2024 12:53:42 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
>> 
>> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
>> 
>> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
>> 
>> Below is a comparison of String.format and concat-based and StringBuilder:
>> 
>> * benchmark java code
>> 
>> public class StringFormat {
>>     @Benchmark
>>     public String stringIntFormat() {
>>         return "%s %d".formatted(s, i);
>>     }
>> 
>>     @Benchmark
>>     public String stringIntConcat() {
>>         return s + " " + i;
>>     }
>> 
>>     @Benchmark
>>     public String stringIntStringBuilder() {
>>         return new StringBuilder(s).append(" ").append(i).toString();
>>     }
>> }
>> 
>> 
>> * benchmark number on macbook m1 pro
>> 
>> Benchmark                            Mode  Cnt   Score   Error  Units
>> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
>> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
>> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
>> 
>> 
>> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
>> 
>> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
>> 
>> d
>> x
>> X
>> s
>> 
>> If necessary, we can add a few more.
>> 
>> 
>> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
>> 
>> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
>> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
>> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
>> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
>> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
>> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
>> 
>> +Benchmark                ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add more test

I added additional tests and debugged all branches in StringFormat to ensure that they were reached.
Is there a way to see the test coverage of jdk core lib code?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2200070223

From duke at openjdk.org  Mon Jul  1 16:30:24 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 1 Jul 2024 16:30:24 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v5]
In-Reply-To: <MK2ILgiqEYFTycQxK8od9ijAkhB7S-YkheXKHrPsQvs=.67965446-9b1c-485c-bf6e-a6c8fe78e378@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <dxGqb52sEIabP7XtXOAlM1BwLI0mXPvXStlpJPGT2pM=.8b46beeb-83e2-46a4-a28b-9b06ff8e82eb@github.com>
 <XvxdHZ6HK3LQOjSAl82GKsP6Df_o2G9dNAjzMUakG8g=.996a0d37-f1cb-49b7-9bbb-403a94bde1b2@github.com>
 <MK2ILgiqEYFTycQxK8od9ijAkhB7S-YkheXKHrPsQvs=.67965446-9b1c-485c-bf6e-a6c8fe78e378@github.com>
Message-ID: <-Fp_E7k01lNePriQNFlzeiakQ_1ulRFtx5Ojkm4wH6o=.d21c8904-4ba5-4bd1-91b0-18e4bc649637@github.com>

On Sat, 29 Jun 2024 19:10:51 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringFormat.java line 48:
>> 
>>> 46:     static String format(String format, Object... args) {
>>> 47:         if (args != null) {
>>> 48:             int off = format.indexOf('%');
>> 
>> nit: instead of not null check, should this short circuit for null/empty args?
>> 
>> Suggestion:
>> 
>>         if (args == null || args.length == 0) {
>>             // no formatting to be done
>>             return format;
>>         }
>> 
>>         int off = format.indexOf('%');
>
> j.u.Formatter supports args == null

When?`args ==?null` or?`args.length ==?0`, then?the?format string can?still contain?`%%` or?`%n`, and?those will?be?formatted to?`"%"` and?[`System?.lineSeparator()`]?respectively.

[`System?.lineSeparator()`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#lineSeparator()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1661292677

From jlu at openjdk.org  Mon Jul  1 17:48:24 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 1 Jul 2024 17:48:24 GMT
Subject: <i18n dev> RFR: 8333396: Performance regression of
 DecimalFormat.format [v15]
In-Reply-To: <Xj5N_ethenooDC7OyjA8lT9SC0hajU8HNlQpB2EhmN4=.fa82acd2-0543-4ba2-b6a1-174b2f7ebadb@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <Xj5N_ethenooDC7OyjA8lT9SC0hajU8HNlQpB2EhmN4=.fa82acd2-0543-4ba2-b6a1-174b2f7ebadb@github.com>
Message-ID: <TWeisTjzi5tcK2Q1EG9_g9HznT2OxIfp3kezKEOqvd4=.083ea133-82f8-4835-a2a7-b1710f083cf0@github.com>

On Mon, 1 Jul 2024 01:48:52 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

test/micro/org/openjdk/bench/java/text/DateFormatterBench.java line 67:

> 65:     @Benchmark
> 66:     public void testFormatDate() {
> 67:         dateFormat.format(date);

Since we are no longer using `Blackhole.consume()`, I would expect `return dateFormat.format(date);`. 
Applies to the other test methods as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1661364046

From duke at openjdk.org  Mon Jul  1 19:17:50 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 1 Jul 2024 19:17:50 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v12]
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <I97xU2qm_jWiyOs9j2e115RTElv0e8wjPKPVbjvKvM8=.6151759b-e582-412a-802f-ceb66364d552@github.com>

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  improve StringFormat benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19956/files
  - new: https://git.openjdk.org/jdk/pull/19956/files/905012af..39289870

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=10-11

  Stats: 117 lines in 1 file changed: 111 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956

PR: https://git.openjdk.org/jdk/pull/19956

From duke at openjdk.org  Mon Jul  1 21:23:19 2024
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 1 Jul 2024 21:23:19 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v5]
In-Reply-To: <-Fp_E7k01lNePriQNFlzeiakQ_1ulRFtx5Ojkm4wH6o=.d21c8904-4ba5-4bd1-91b0-18e4bc649637@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <dxGqb52sEIabP7XtXOAlM1BwLI0mXPvXStlpJPGT2pM=.8b46beeb-83e2-46a4-a28b-9b06ff8e82eb@github.com>
 <XvxdHZ6HK3LQOjSAl82GKsP6Df_o2G9dNAjzMUakG8g=.996a0d37-f1cb-49b7-9bbb-403a94bde1b2@github.com>
 <MK2ILgiqEYFTycQxK8od9ijAkhB7S-YkheXKHrPsQvs=.67965446-9b1c-485c-bf6e-a6c8fe78e378@github.com>
 <-Fp_E7k01lNePriQNFlzeiakQ_1ulRFtx5Ojkm4wH6o=.d21c8904-4ba5-4bd1-91b0-18e4bc649637@github.com>
Message-ID: <0gzOwxj2jI3DCuLEn_gsR9T_klQKD_iRp9tLSHb_UZ0=.f5cef84d-5dc9-40eb-a5d3-e22be79251d3@github.com>

On Mon, 1 Jul 2024 16:28:09 GMT, ExE Boss <duke at openjdk.org> wrote:

>> j.u.Formatter supports args == null
>
> When?`args ==?null` or?`args.length ==?0`, then?the?format string can?still contain?`%%` or?`%n`, and?those will?be?formatted to?`"%"` and?[`System?.lineSeparator()`]?respectively.
> 
> [`System?.lineSeparator()`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#lineSeparator()

Yeah, if args is null or empty and there are format specifiers in the format string it should throw `IllegalFormatException`. To @liach ?s earlier comments, `String.format` likely needs more exhaustive unit tests covering various positive and negative test cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1661553502

From duke at openjdk.org  Tue Jul  2 00:57:35 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 2 Jul 2024 00:57:35 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v12]
In-Reply-To: <I97xU2qm_jWiyOs9j2e115RTElv0e8wjPKPVbjvKvM8=.6151759b-e582-412a-802f-ceb66364d552@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <I97xU2qm_jWiyOs9j2e115RTElv0e8wjPKPVbjvKvM8=.6151759b-e582-412a-802f-ceb66364d552@github.com>
Message-ID: <FMjuqH9fPWFEnxSMzdTUCWMloxVL_56_r2S0SyM2JMY=.b36b507e-a3e3-467a-a71f-014111ad277f@github.com>

On Mon, 1 Jul 2024 19:17:50 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
>> 
>> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
>> 
>> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
>> 
>> Below is a comparison of String.format and concat-based and StringBuilder:
>> 
>> * benchmark java code
>> 
>> public class StringFormat {
>>     @Benchmark
>>     public String stringIntFormat() {
>>         return "%s %d".formatted(s, i);
>>     }
>> 
>>     @Benchmark
>>     public String stringIntConcat() {
>>         return s + " " + i;
>>     }
>> 
>>     @Benchmark
>>     public String stringIntStringBuilder() {
>>         return new StringBuilder(s).append(" ").append(i).toString();
>>     }
>> }
>> 
>> 
>> * benchmark number on macbook m1 pro
>> 
>> Benchmark                            Mode  Cnt   Score   Error  Units
>> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
>> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
>> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
>> 
>> 
>> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
>> 
>> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
>> 
>> d
>> x
>> X
>> s
>> 
>> If necessary, we can add a few more.
>> 
>> 
>> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
>> 
>> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
>> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
>> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
>> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
>> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
>> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
>> 
>> +Benchmark                ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve StringFormat benchmark

I updated the StringFormat benchmark. Here are the performance numbers on a MacBook M1 Pro:

# baseline 5d866bf17d96bd0f0e4545d7eee5912eda2e3a94
-Benchmark                               Mode  Cnt    Score    Error  Units
-StringFormat.complexFormat              avgt   15  980.323 ? 77.227  ns/op
-StringFormat.decimalFormat              avgt   15  277.042 ? 17.070  ns/op
-StringFormat.intFormat                  avgt   15   61.400 ?  0.269  ns/op
-StringFormat.intFormatUtf16             avgt   15  126.581 ?  2.270  ns/op
-StringFormat.intHexFormat               avgt   15  232.125 ? 79.431  ns/op
-StringFormat.intHexFormatUtf16          avgt   15  113.980 ?  1.537  ns/op
-StringFormat.intHexUFormat              avgt   15  202.426 ? 10.029  ns/op
-StringFormat.intHexUFormatUtf16         avgt   15  132.994 ?  3.183  ns/op
-StringFormat.intIntFormat               avgt   15  138.301 ?  7.932  ns/op
-StringFormat.intIntFormatUtf16          avgt   15  131.910 ?  7.142  ns/op
-StringFormat.intOctalFormat             avgt   15  249.411 ? 89.041  ns/op
-StringFormat.intOctalFormatUtf16        avgt   15  117.244 ?  1.426  ns/op
-StringFormat.stringFormat               avgt   15   63.645 ?  3.791  ns/op
-StringFormat.stringFormatUtf16          avgt   15  150.495 ?  9.363  ns/op
-StringFormat.stringIntFormat            avgt   15  123.888 ?  4.177  ns/op
-StringFormat.stringIntFormatUtf16       avgt   15  174.825 ? 18.766  ns/op
-StringFormat.stringIntHexFormat         avgt   15  150.750 ?  4.177  ns/op
-StringFormat.stringIntHexUFormat        avgt   15  162.287 ?  5.530  ns/op
-StringFormat.stringIntOctalFormat       avgt   15  157.474 ?  6.569  ns/op
-StringFormat.stringIntOctalFormatUtf16  avgt   15  151.507 ? 20.590  ns/op
-StringFormat.stringIntRFormat           avgt   15  135.326 ?  1.884  ns/op
-StringFormat.stringIntRFormatUtf16      avgt   15  196.023 ?  6.874  ns/op
-StringFormat.stringWidthIntFormat       avgt   15  151.324 ?  2.308  ns/op
-StringFormat.stringWidthIntFormatUtf16  avgt   15  136.286 ?  2.770  ns/op
-StringFormat.widthStringFormat          avgt   15   93.960 ? 22.499  ns/op
-StringFormat.widthStringFormatUtf16     avgt   15  127.997 ? 18.408  ns/op
-StringFormat.widthStringIntFormat       avgt   15  150.131 ? 12.496  ns/op
-StringFormat.widthStringIntFormatUtf16  avgt   15  159.734 ?  3.821  ns/op

# current 392898703ce9907b84d51098ef7b8f536d355742
+Benchmark                               Mode  Cnt    Score    Error  Units
+StringFormat.complexFormat              avgt   15  909.352 ? 46.681  ns/op
+StringFormat.decimalFormat              avgt   15  290.069 ? 20.778  ns/op
+StringFormat.intFormat                  avgt   15   11.211 ?  0.047  ns/op
+StringFormat.intFormatUtf16             avgt   15   11.799 ?  0.032  ns/op
+StringFormat.intHexFormat               avgt   15   35.550 ?  7.420  ns/op
+StringFormat.intHexFormatUtf16          avgt   15   35.680 ?  1.608  ns/op
+StringFormat.intHexUFormat              avgt   15   31.229 ?  3.043  ns/op
+StringFormat.intHexUFormatUtf16         avgt   15   46.915 ?  7.014  ns/op
+StringFormat.intIntFormat               avgt   15   31.573 ?  0.539  ns/op
+StringFormat.intIntFormatUtf16          avgt   15   31.595 ?  0.345  ns/op
+StringFormat.intOctalFormat             avgt   15  265.869 ? 60.233  ns/op
+StringFormat.intOctalFormatUtf16        avgt   15  153.843 ? 18.901  ns/op
+StringFormat.stringFormat               avgt   15   10.852 ?  0.009  ns/op
+StringFormat.stringFormatUtf16          avgt   15   13.422 ?  0.203  ns/op
+StringFormat.stringIntFormat            avgt   15   36.833 ?  5.495  ns/op
+StringFormat.stringIntFormatUtf16       avgt   15   21.482 ?  0.043  ns/op
+StringFormat.stringIntHexFormat         avgt   15   19.926 ?  0.041  ns/op
+StringFormat.stringIntHexUFormat        avgt   15   19.954 ?  0.055  ns/op
+StringFormat.stringIntOctalFormat       avgt   15  137.748 ?  1.796  ns/op
+StringFormat.stringIntOctalFormatUtf16  avgt   15  126.615 ? 13.933  ns/op
+StringFormat.stringIntRFormat           avgt   15   37.231 ?  2.449  ns/op
+StringFormat.stringIntRFormatUtf16      avgt   15   38.406 ?  0.577  ns/op
+StringFormat.stringWidthIntFormat       avgt   15   43.897 ?  6.464  ns/op
+StringFormat.stringWidthIntFormatUtf16  avgt   15   28.683 ?  2.147  ns/op
+StringFormat.widthStringFormat          avgt   15   11.421 ?  0.021  ns/op
+StringFormat.widthStringFormatUtf16     avgt   15   12.228 ?  0.023  ns/op
+StringFormat.widthStringIntFormat       avgt   15   38.051 ?  6.635  ns/op
+StringFormat.widthStringIntFormatUtf16  avgt   15   23.347 ?  1.049  ns/op+


In the scenario where the performance is improved or worse through fastpath and then falls back to j.u.Formatter, it is confusing.

|   | baseline  | current | delta |
| --- | --- | --- | --- |
| StringFormat.complexFormat | 980.323 | 909.352 | 7.80% |
| StringFormat.decimalFormat | 277.042 | 290.069 | -4.49% |
| StringFormat.intOctalFormat | 249.411 | 265.869 | -6.19% |
| StringFormat.intOctalFormatUtf16 | 117.244 | 153.843 | -23.79% |
| StringFormat.stringIntOctalFormat | 157.474 | 137.748 | 14.32% |
| StringFormat.stringIntOctalFormatUtf16 | 151.507 | 126.615 | 19.66% |

In other scenarios hit by fastpath, the performance is significantly improved.

|   | baseline  | current | delta |
| --- | --- | --- | --- |
| StringFormat.intFormat | 61.400 | 11.211 | 447.68% |
| StringFormat.intFormatUtf16 | 126.581 | 11.799 | 972.81% |
| StringFormat.intHexFormat | 232.125 | 35.550 | 552.95% |
| StringFormat.intHexFormatUtf16 | 113.980 | 35.680 | 219.45% |
| StringFormat.intHexUFormat | 202.426 | 31.229 | 548.20% |
| StringFormat.intHexUFormatUtf16 | 132.994 | 46.915 | 183.48% |
| StringFormat.intIntFormat | 138.301 | 31.573 | 338.04% |
| StringFormat.intIntFormatUtf16 | 131.910 | 31.595 | 317.50% |
| StringFormat.stringFormat | 63.645 | 10.852 | 486.48% |
| StringFormat.stringFormatUtf16 | 150.495 | 13.422 | 1021.26% |
| StringFormat.stringIntFormat | 123.888 | 36.833 | 236.35% |
| StringFormat.stringIntFormatUtf16 | 174.825 | 21.482 | 713.82% |
| StringFormat.stringIntHexFormat | 150.750 | 19.926 | 656.55% |
| StringFormat.stringIntHexUFormat | 162.287 | 19.954 | 713.31% |
| StringFormat.stringIntRFormat | 135.326 | 37.231 | 263.48% |
| StringFormat.stringIntRFormatUtf16 | 196.023 | 38.406 | 410.40% |
| StringFormat.stringWidthIntFormat | 151.324 | 43.897 | 244.73% |
| StringFormat.stringWidthIntFormatUtf16 | 136.286 | 28.683 | 375.15% |
| StringFormat.widthStringFormat | 93.960 | 11.421 | 722.70% |
| StringFormat.widthStringFormatUtf16 | 127.997 | 12.228 | 946.75% |
| StringFormat.widthStringIntFormat | 150.131 | 38.051 | 294.55% |
| StringFormat.widthStringIntFormatUtf16 | 159.734 | 23.347 | 584.17% |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2201575948

From duke at openjdk.org  Tue Jul  2 02:13:50 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 2 Jul 2024 02:13:50 GMT
Subject: <i18n dev> RFR: 8333396: Performance regression of
 DecimalFormat.format [v16]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <9axU7oSSiv3hbiHb71VynRC-RSn6iKmW8EWhGFpyvlA=.57cf9880-ac37-4591-80bd-0439b1144351@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Performance regression of DecimalFormat.format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/da09d85a..7122c2c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=14-15

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From rriggs at openjdk.org  Tue Jul  2 13:54:23 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 2 Jul 2024 13:54:23 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v12]
In-Reply-To: <I97xU2qm_jWiyOs9j2e115RTElv0e8wjPKPVbjvKvM8=.6151759b-e582-412a-802f-ceb66364d552@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <I97xU2qm_jWiyOs9j2e115RTElv0e8wjPKPVbjvKvM8=.6151759b-e582-412a-802f-ceb66364d552@github.com>
Message-ID: <yYr12ANlF31KrpNzL7TgnpGdYQKu7vCRXABQogZntEs=.17a8feb0-655b-462d-bcb5-78c34a636b84@github.com>

On Mon, 1 Jul 2024 19:17:50 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
>> 
>> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
>> 
>> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
>> 
>> Below is a comparison of String.format and concat-based and StringBuilder:
>> 
>> * benchmark java code
>> 
>> public class StringFormat {
>>     @Benchmark
>>     public String stringIntFormat() {
>>         return "%s %d".formatted(s, i);
>>     }
>> 
>>     @Benchmark
>>     public String stringIntConcat() {
>>         return s + " " + i;
>>     }
>> 
>>     @Benchmark
>>     public String stringIntStringBuilder() {
>>         return new StringBuilder(s).append(" ").append(i).toString();
>>     }
>> }
>> 
>> 
>> * benchmark number on macbook m1 pro
>> 
>> Benchmark                            Mode  Cnt   Score   Error  Units
>> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
>> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
>> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
>> 
>> 
>> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
>> 
>> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
>> 
>> d
>> x
>> X
>> s
>> 
>> If necessary, we can add a few more.
>> 
>> 
>> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
>> 
>> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
>> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
>> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
>> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
>> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
>> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
>> 
>> +Benchmark                ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve StringFormat benchmark

I have serious concerns about going forward with this optimization. 
It creates duplicate and fragile code that becomes a maintenance overhead.
It reduces the performance of the non-covered cases and does nothing for the other cases using Formatter.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2203237835

From duke at openjdk.org  Tue Jul  2 14:04:52 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 2 Jul 2024 14:04:52 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v13]
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <9CkX_juOjiGeyju_DxzM8DcDc2WU3K4F3r7Ov7ahoDs=.4babcc32-7731-452b-9b80-5d37cd36f2d5@github.com>

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  optimize width padding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19956/files
  - new: https://git.openjdk.org/jdk/pull/19956/files/39289870..f1ae26a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=11-12

  Stats: 10 lines in 1 file changed: 4 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956

PR: https://git.openjdk.org/jdk/pull/19956

From naoto at openjdk.org  Wed Jul  3 16:58:26 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 Jul 2024 16:58:26 GMT
Subject: <i18n dev> RFR: 8330954: since-checker - Fix remaining @ since
 tags in java.base [v7]
In-Reply-To: <IBD0_AMYf7zQCygu2z3RR4KNBG6J8ZQ3HrSXWMkr0gQ=.032e6176-313d-441e-9b8e-3aa4ce515f17@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <IBD0_AMYf7zQCygu2z3RR4KNBG6J8ZQ3HrSXWMkr0gQ=.032e6176-313d-441e-9b8e-3aa4ce515f17@github.com>
Message-ID: <zDEgLECWXYrflK1gd-iXLo6jyR06r7gVs7UdKJxt1Jo=.488b2645-f4bc-422f-9d4e-f1fce398e0ee@github.com>

On Fri, 28 Jun 2024 11:11:51 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
>> This is related to #18934 and my work around the `@since` checker feature.
>> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
>> 
>> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
>> 
>> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
>> 
>> 
>> 
>> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
>> 
>> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
>> 
>> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
>> 
>> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
>> 
>> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
>> 
>> 
>> TIA
>
> Nizar Benalla 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 14 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8330954
>  - Add new line when having multi-line doc comment
>  - Merge remote-tracking branch 'upstream/master' into 8330954
>  - Merge remote-tracking branch 'upstream/master' into 8330954
>  - (C)
>  - (C)
>  - Move security classes changes to pr18373
>  - remove couple extra lines
>  - Pull request is now only about `@since` tags, might add an other commit
>  - add one more `{inheritDoc}` to `CompletableFuture.state`
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/36d15a13...afca07bf

OK, I look at other areas and I believe they are fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2206794418

From duke at openjdk.org  Wed Jul  3 21:51:37 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 3 Jul 2024 21:51:37 GMT
Subject: <i18n dev> RFR: 8335645: j.u.Formatter#trailingZeros improved with
 String repeat
Message-ID: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>

In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros

-------------

Commit messages:
 - use StringBuilder#repeat

Changes: https://git.openjdk.org/jdk/pull/20018/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20018&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335645
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20018.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20018/head:pull/20018

PR: https://git.openjdk.org/jdk/pull/20018

From liach at openjdk.org  Wed Jul  3 21:55:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Jul 2024 21:55:20 GMT
Subject: <i18n dev> RFR: 8335645: j.u.Formatter#trailingZeros improved
 with String repeat
In-Reply-To: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>
References: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>
Message-ID: <KQeZC5QUYkS6ovgwwsnYQfFobmBwQvN1WEawlbYfaAQ=.da20704b-43d4-4803-a75e-ff6121e37a0f@github.com>

On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros

Marked as reviewed by liach (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20018#pullrequestreview-2157534378

From jlu at openjdk.org  Wed Jul  3 22:19:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 3 Jul 2024 22:19:18 GMT
Subject: <i18n dev> RFR: 8335645: j.u.Formatter#trailingZeros improved
 with String repeat
In-Reply-To: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>
References: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>
Message-ID: <QIJDiTRDhvoi88sglBvz_MGnUxQok-NS1Goxf9XqFrI=.e94c286a-70cc-4185-9ea6-5320efb51ba4@github.com>

On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros

+1

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20018#pullrequestreview-2157583915

From naoto at openjdk.org  Wed Jul  3 22:36:18 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 Jul 2024 22:36:18 GMT
Subject: <i18n dev> RFR: 8335645: j.u.Formatter#trailingZeros improved
 with String repeat
In-Reply-To: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>
References: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>
Message-ID: <KYbdPyCTo3-iAmUYBd5t-HrTflK5wk69SeW2PrMrgKY=.60f58f84-7951-4f97-8bf2-75eb99b469d5@github.com>

On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20018#pullrequestreview-2157610512

From duke at openjdk.org  Wed Jul  3 22:56:18 2024
From: duke at openjdk.org (duke)
Date: Wed, 3 Jul 2024 22:56:18 GMT
Subject: <i18n dev> RFR: 8335645: j.u.Formatter#trailingZeros improved
 with String repeat
In-Reply-To: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>
References: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>
Message-ID: <b9lpkpJ8UQudv7jGGSLFA_SQ-j4cC35WWZXVSKGkH0k=.2843636c-73a1-4fd0-b42e-68e80b99d566@github.com>

On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros

@wenshao 
Your change (at version a98bd05c857d0a04dfad471dd28f905be1345376) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20018#issuecomment-2207438128

From naoto at openjdk.org  Wed Jul  3 23:10:18 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 Jul 2024 23:10:18 GMT
Subject: <i18n dev> RFR: 8335645: j.u.Formatter#trailingZeros improved
 with String repeat
In-Reply-To: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>
References: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>
Message-ID: <AnCvD3SRjb2cksbOVuRD74ALrawsbJLkFX8dEz_qPOM=.52b1d9f3-8b01-4044-a9d6-647116b0af5f@github.com>

On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros

As a general rule, please wait for at least 24 hours to integrate, for devs around the globe to take a look (unless emergency such as a build break).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20018#issuecomment-2207447047

From liach at openjdk.org  Wed Jul  3 23:13:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Jul 2024 23:13:18 GMT
Subject: <i18n dev> RFR: 8335645: j.u.Formatter#trailingZeros improved
 with String repeat
In-Reply-To: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>
References: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>
Message-ID: <HfI68CxeltSdpGiYSgafCvj37F06jZZfKWYsmhSmAqA=.6b65112d-00a1-4850-b03a-8e96e5e0d630@github.com>

On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros

See https://openjdk.org/guide/#life-of-a-pr point 6 for the 24-hour wait rule.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20018#issuecomment-2207452838

From duke at openjdk.org  Thu Jul  4 00:39:19 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 4 Jul 2024 00:39:19 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v13]
In-Reply-To: <9CkX_juOjiGeyju_DxzM8DcDc2WU3K4F3r7Ov7ahoDs=.4babcc32-7731-452b-9b80-5d37cd36f2d5@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <9CkX_juOjiGeyju_DxzM8DcDc2WU3K4F3r7Ov7ahoDs=.4babcc32-7731-452b-9b80-5d37cd36f2d5@github.com>
Message-ID: <n5zMxG2WA2-JI2jY0Lp2mxDzKgHxJ5InFI21e-mKA68=.55608602-5a6c-47f5-9eb9-604d51a360fd@github.com>

On Tue, 2 Jul 2024 14:04:52 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
>> 
>> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
>> 
>> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
>> 
>> Below is a comparison of String.format and concat-based and StringBuilder:
>> 
>> * benchmark java code
>> 
>> public class StringFormat {
>>     @Benchmark
>>     public String stringIntFormat() {
>>         return "%s %d".formatted(s, i);
>>     }
>> 
>>     @Benchmark
>>     public String stringIntConcat() {
>>         return s + " " + i;
>>     }
>> 
>>     @Benchmark
>>     public String stringIntStringBuilder() {
>>         return new StringBuilder(s).append(" ").append(i).toString();
>>     }
>> }
>> 
>> 
>> * benchmark number on macbook m1 pro
>> 
>> Benchmark                            Mode  Cnt   Score   Error  Units
>> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
>> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
>> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
>> 
>> 
>> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
>> 
>> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
>> 
>> d
>> x
>> X
>> s
>> 
>> If necessary, we can add a few more.
>> 
>> 
>> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
>> 
>> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
>> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
>> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
>> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
>> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
>> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
>> 
>> +Benchmark                ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimize width padding

As you said above, this optimization has costs, including maintenance and fallback costs. I plan to optimize j.u.Formatter. however, the performance optimization on j.u.Formatter cannot achieve this optimization effect.

The benefit of this optimization is that it approaches the performance of String.concat and hand-written StringBuilder, but exceeds them in ease of use based on String.format.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2207674846

From duke at openjdk.org  Thu Jul  4 01:37:28 2024
From: duke at openjdk.org (lingjun-cg)
Date: Thu, 4 Jul 2024 01:37:28 GMT
Subject: <i18n dev> RFR: 8333396: Performance regression of
 DecimalFormat.format [v8]
In-Reply-To: <fzhyfD_RFKPTKh7Fy1gPkAck6DElQkoInCSLcICs31U=.d5418456-4698-47e3-b187-5f0aae5b7c34@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
 <julUD8fYOzQKcVXJIvBs0XdHwkigMmCB2gNg_sWonjE=.ad9fddd3-91c7-4fbe-a578-7886ad46edb4@github.com>
 <fzhyfD_RFKPTKh7Fy1gPkAck6DElQkoInCSLcICs31U=.d5418456-4698-47e3-b187-5f0aae5b7c34@github.com>
Message-ID: <A_iX44Kj2t5RlZDlnAasauQ-Uoq_f4hl_azZPKgV0Sg=.fa9f9aa2-8193-4195-b28f-811edde83d31@github.com>

On Tue, 25 Jun 2024 19:33:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I did not mean to introduce a public API for this change (if we do, the fix cannot be backported). I thought we could define a package private one, but based on your observation, it may get messier... So I agree that falling back to `StringBuf` is the way to go, IMO.
>
>> So, considering all the information given, is it enough to start our new review process? @naotoj @liach @justin-curtis-lu
> 
> Well, I was suggesting the same buffer proxying for other Format classes than NumberFormat subclasses, such as DateFormat so that they would have the same performance benefit. Would you be willing to do that too?

Thanks all for your valuable suggestions. All suggestions were accepted.  Is it enough to start our new review process? @naotoj @justin-curtis-lu @liach @irisclark

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2207831524

From jlu at openjdk.org  Thu Jul  4 07:29:27 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 4 Jul 2024 07:29:27 GMT
Subject: <i18n dev> RFR: 8333396: Performance regression of
 DecimalFormat.format [v16]
In-Reply-To: <9axU7oSSiv3hbiHb71VynRC-RSn6iKmW8EWhGFpyvlA=.57cf9880-ac37-4591-80bd-0439b1144351@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9axU7oSSiv3hbiHb71VynRC-RSn6iKmW8EWhGFpyvlA=.57cf9880-ac37-4591-80bd-0439b1144351@github.com>
Message-ID: <u_XQtWHu2t16PQVIDekaEAx7iRng0lV5GqcfbhC0pag=.0f091b3b-38e2-42a3-8408-236e99abc0e1@github.com>

On Tue, 2 Jul 2024 02:13:50 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

Thanks @lingjun-cg for your updates.

I went through the newest version and the implementation changes look OK to me. It is a little easier to review without the intermediate StringBuilder method.
It is a large change, so it is good there are multiple sets of eyes here. We will of course still need approval from a **Reviewer**.

Something to note is that there is now some wording in the specification of some java.text.Format.* classes that is technically untrue. For example, in `Format.format(Object obj)`, it states the method is equivalent to calling `Format.format(obj, new StringBuffer(), new FieldPosition(0)).toString())`. It is not the biggest deal since it is just minor supplementary info and can probably simply be removed. However, this should be done as a separate issue, since we would like to backport the changes in this PR.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2158180263

From liach at openjdk.org  Thu Jul  4 12:09:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 Jul 2024 12:09:19 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v13]
In-Reply-To: <9CkX_juOjiGeyju_DxzM8DcDc2WU3K4F3r7Ov7ahoDs=.4babcc32-7731-452b-9b80-5d37cd36f2d5@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <9CkX_juOjiGeyju_DxzM8DcDc2WU3K4F3r7Ov7ahoDs=.4babcc32-7731-452b-9b80-5d37cd36f2d5@github.com>
Message-ID: <8wNdB7ts48FsMTrcXCoSy-t2de4F9aWMp-MedvDQ0Jk=.f8dcc125-fcb5-4e5d-abc6-bddd509c9db3@github.com>

On Tue, 2 Jul 2024 14:04:52 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
>> 
>> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
>> 
>> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
>> 
>> Below is a comparison of String.format and concat-based and StringBuilder:
>> 
>> * benchmark java code
>> 
>> public class StringFormat {
>>     @Benchmark
>>     public String stringIntFormat() {
>>         return "%s %d".formatted(s, i);
>>     }
>> 
>>     @Benchmark
>>     public String stringIntConcat() {
>>         return s + " " + i;
>>     }
>> 
>>     @Benchmark
>>     public String stringIntStringBuilder() {
>>         return new StringBuilder(s).append(" ").append(i).toString();
>>     }
>> }
>> 
>> 
>> * benchmark number on macbook m1 pro
>> 
>> Benchmark                            Mode  Cnt   Score   Error  Units
>> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
>> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
>> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
>> 
>> 
>> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
>> 
>> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
>> 
>> d
>> x
>> X
>> s
>> 
>> If necessary, we can add a few more.
>> 
>> 
>> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
>> 
>> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
>> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
>> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
>> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
>> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
>> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
>> 
>> +Benchmark                ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimize width padding

As complex as this optimization may appear, I think we can probably consider breaking it into more maintainable parts:

1. Reducing appendable allocation if we just format to formatter once
2. Fast path for parsing 1 or 2-arg format strings
3. Fast writing if the format arguments are simple number or strings

I think you might look at `Formatter::parse` internal factory:
1. We can probably do a `Formatter.parse` before we allocate formatter + appendable, and just pass the parsed result to the formatter to skip some pre-processing
2. If the parse result is 1 or 2 args, we can try to go through a new fast path if it is helpful
3. If the parse result knows what the resulting string will look like (length, and maybe coder; thus we need to change the result to like a record) we can ask StringBuilder to preallocate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2208803578

From nbenalla at openjdk.org  Thu Jul  4 14:38:25 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 4 Jul 2024 14:38:25 GMT
Subject: <i18n dev> RFR: 8330954: since-checker - Fix remaining @ since
 tags in java.base [v7]
In-Reply-To: <IBD0_AMYf7zQCygu2z3RR4KNBG6J8ZQ3HrSXWMkr0gQ=.032e6176-313d-441e-9b8e-3aa4ce515f17@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <IBD0_AMYf7zQCygu2z3RR4KNBG6J8ZQ3HrSXWMkr0gQ=.032e6176-313d-441e-9b8e-3aa4ce515f17@github.com>
Message-ID: <BKj4It6IqruflaHI7PZloUkZUqQ0Fz3Qo2nSyjp3S8I=.27834fbd-f44d-45f7-8167-ecf31cfd3f95@github.com>

On Fri, 28 Jun 2024 11:11:51 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
>> This is related to #18934 and my work around the `@since` checker feature.
>> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
>> 
>> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
>> 
>> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
>> 
>> 
>> 
>> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
>> 
>> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
>> 
>> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
>> 
>> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
>> 
>> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
>> 
>> 
>> TIA
>
> Nizar Benalla 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 14 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8330954
>  - Add new line when having multi-line doc comment
>  - Merge remote-tracking branch 'upstream/master' into 8330954
>  - Merge remote-tracking branch 'upstream/master' into 8330954
>  - (C)
>  - (C)
>  - Move security classes changes to pr18373
>  - remove couple extra lines
>  - Pull request is now only about `@since` tags, might add an other commit
>  - add one more `{inheritDoc}` to `CompletableFuture.state`
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/f122d936...afca07bf

Thank you Naoto for checking, and thanks Chen!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2209141939

From duke at openjdk.org  Thu Jul  4 14:38:25 2024
From: duke at openjdk.org (duke)
Date: Thu, 4 Jul 2024 14:38:25 GMT
Subject: <i18n dev> RFR: 8330954: since-checker - Fix remaining @ since
 tags in java.base [v7]
In-Reply-To: <IBD0_AMYf7zQCygu2z3RR4KNBG6J8ZQ3HrSXWMkr0gQ=.032e6176-313d-441e-9b8e-3aa4ce515f17@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <IBD0_AMYf7zQCygu2z3RR4KNBG6J8ZQ3HrSXWMkr0gQ=.032e6176-313d-441e-9b8e-3aa4ce515f17@github.com>
Message-ID: <WB3SccQjATQz3WIAt6y-TyE4oCHwVeUAOLKn05k3HJI=.6ff800b0-fd2b-4d15-9cc0-ba0c22cc4469@github.com>

On Fri, 28 Jun 2024 11:11:51 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
>> This is related to #18934 and my work around the `@since` checker feature.
>> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
>> 
>> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
>> 
>> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
>> 
>> 
>> 
>> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
>> 
>> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
>> 
>> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
>> 
>> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
>> 
>> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
>> 
>> 
>> TIA
>
> Nizar Benalla 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 14 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8330954
>  - Add new line when having multi-line doc comment
>  - Merge remote-tracking branch 'upstream/master' into 8330954
>  - Merge remote-tracking branch 'upstream/master' into 8330954
>  - (C)
>  - (C)
>  - Move security classes changes to pr18373
>  - remove couple extra lines
>  - Pull request is now only about `@since` tags, might add an other commit
>  - add one more `{inheritDoc}` to `CompletableFuture.state`
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/f122d936...afca07bf

@nizarbenalla 
Your change (at version afca07bfc06b31c4b689cb9051cc114328b389a1) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2209143098

From nbenalla at openjdk.org  Thu Jul  4 15:47:27 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 4 Jul 2024 15:47:27 GMT
Subject: <i18n dev> Integrated: 8330954: since-checker - Fix remaining @
 since tags in java.base
In-Reply-To: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
Message-ID: <dO6qEZvT9IeZwTUYh6vD97Pn5dQLzEpc9v-1rDnPYL4=.3d8fbf4e-3047-4f80-a17c-76c42546c3c0@github.com>

On Thu, 25 Apr 2024 14:29:27 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
> 
> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
> 
> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
> 
> 
> 
> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
> 
> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
> 
> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
> 
> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
> 
> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
> 
> 
> TIA

This pull request has now been integrated.

Changeset: f4fa35e2
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f4fa35e28b9881729ac47c8518e758bba676fdec
Stats:     71 lines in 12 files changed: 67 ins; 2 del; 2 mod

8330954: since-checker - Fix remaining @ since tags in java.base

Reviewed-by: liach, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/18954

From duke at openjdk.org  Fri Jul  5 12:56:21 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 5 Jul 2024 12:56:21 GMT
Subject: <i18n dev> Integrated: 8335645: j.u.Formatter#trailingZeros
 improved with String repeat
In-Reply-To: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>
References: <pWx7Z0-UWCD8HmluMBq0uNO-KFdPAOYtnF1OPfkr8bo=.0989fdad-a0c0-42e5-824a-fb1ae347f6af@github.com>
Message-ID: <UuLXxe8rwW7Adx29Lnqojy96WlKTsLyFDgzRDAgNSdU=.629cfc80-2318-4376-83fa-8a5a9ad297a1@github.com>

On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros

This pull request has now been integrated.

Changeset: 194425d7
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/194425d7875ef42fce52516ed59c81ee97720399
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8335645: j.u.Formatter#trailingZeros improved with String repeat

Reviewed-by: liach, jlu, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/20018

From duke at openjdk.org  Fri Jul  5 16:30:35 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 5 Jul 2024 16:30:35 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v13]
In-Reply-To: <9CkX_juOjiGeyju_DxzM8DcDc2WU3K4F3r7Ov7ahoDs=.4babcc32-7731-452b-9b80-5d37cd36f2d5@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <9CkX_juOjiGeyju_DxzM8DcDc2WU3K4F3r7Ov7ahoDs=.4babcc32-7731-452b-9b80-5d37cd36f2d5@github.com>
Message-ID: <OTuXItBbo7pngvJxJG5WuvQRqbUS2oUK9l90vGx7PAQ=.c51c3da7-3b71-40c8-b242-9e380129bc75@github.com>

On Tue, 2 Jul 2024 14:04:52 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
>> 
>> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
>> 
>> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
>> 
>> Below is a comparison of String.format and concat-based and StringBuilder:
>> 
>> * benchmark java code
>> 
>> public class StringFormat {
>>     @Benchmark
>>     public String stringIntFormat() {
>>         return "%s %d".formatted(s, i);
>>     }
>> 
>>     @Benchmark
>>     public String stringIntConcat() {
>>         return s + " " + i;
>>     }
>> 
>>     @Benchmark
>>     public String stringIntStringBuilder() {
>>         return new StringBuilder(s).append(" ").append(i).toString();
>>     }
>> }
>> 
>> 
>> * benchmark number on macbook m1 pro
>> 
>> Benchmark                            Mode  Cnt   Score   Error  Units
>> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
>> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
>> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
>> 
>> 
>> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
>> 
>> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
>> 
>> d
>> x
>> X
>> s
>> 
>> If necessary, we can add a few more.
>> 
>> 
>> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
>> 
>> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
>> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
>> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
>> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
>> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
>> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
>> 
>> +Benchmark                ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimize width padding

https://github.com/openjdk/jdk/pull/20055

I submitted a new PR to modify j.u.Formatter. There are also many changes. I hope to get your patient review.

@RogerRiggs @liach @cl4es

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2211143875

From jlu at openjdk.org  Fri Jul  5 16:57:36 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 5 Jul 2024 16:57:36 GMT
Subject: <i18n dev> RFR: 8333396: Performance regression of
 DecimalFormat.format [v16]
In-Reply-To: <9axU7oSSiv3hbiHb71VynRC-RSn6iKmW8EWhGFpyvlA=.57cf9880-ac37-4591-80bd-0439b1144351@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9axU7oSSiv3hbiHb71VynRC-RSn6iKmW8EWhGFpyvlA=.57cf9880-ac37-4591-80bd-0439b1144351@github.com>
Message-ID: <VEcg_aqYyXOsLN91r-PxnP4rUaORGcegHYlzmQLuiCE=.6bc10d29-77bb-4dee-9fac-49a393d3f042@github.com>

On Tue, 2 Jul 2024 02:13:50 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

Following up on my previous comment regarding the _untrue wording_.

I no longer think we can just split the implementation and specification portion of this PR into two issues, since if we backport the implementation only, the specification would now be violated for the back-ported releases. We may have to just include the specification in this issue as well, (which will require a CSR and no longer means we can backport this change).

-------------

Changes requested by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2161032118

From duke at openjdk.org  Fri Jul  5 18:42:43 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 5 Jul 2024 18:42:43 GMT
Subject: <i18n dev> =?utf-8?b?UkZSOiA4MzM1NzkxOiBTcGVlZCDigIvigIt1cCBq?=
 =?utf-8?q?=2Eu=2EFormatter_=26_String=2Eformat?=
Message-ID: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>

String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently.


Improved performance includes the following:

## 1. Write directly during the parse process to reduce object allocation.

In the current Formatter implementation, some objects do not need to be allocated, such as:


class Formatter {
    public Formatter format(Locale l, String format, Object ... args) {
    	List<FormatString> fsa = parse(format);
    	// ...
    }

    static List<FormatString> parse(String s) {
    	ArrayList<FormatString> al = new ArrayList<>();

        while (i < max) {
            int n = s.indexOf('%', i);
            if (n < 0) {
                // 
                al.add(new FixedString(s, i, max));
            }
        }
    }
}

In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List<FormatString> fsa` to store it.

## 2. Fast path print
Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method.

## 3. String.format directly calls j.u.Formatter
String.format directly calls j.u.Formatter via SharedSecrets to improve performance

-------------

Commit messages:
 - speed up j.u.Formatter & String.format

Changes: https://git.openjdk.org/jdk/pull/20055/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335791
  Stats: 710 lines in 6 files changed: 586 ins; 60 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/20055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20055/head:pull/20055

PR: https://git.openjdk.org/jdk/pull/20055

From duke at openjdk.org  Fri Jul  5 18:42:44 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 5 Jul 2024 18:42:44 GMT
Subject: <i18n dev> =?utf-8?b?UkZSOiA4MzM1NzkxOiBTcGVlZCDigIvigIt1cCBq?=
 =?utf-8?q?=2Eu=2EFormatter_=26_String=2Eformat?=
In-Reply-To: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
References: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
Message-ID: <N8ehupeoDCIUTodFce1ygk0nRuHcNsfRvpB38sf4Ras=.768f490d-e685-4774-9ffb-775e66c9f83f@github.com>

On Fri, 5 Jul 2024 15:40:24 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently.
> 
> 
> Improved performance includes the following:
> 
> ## 1. Write directly during the parse process to reduce object allocation.
> 
> In the current Formatter implementation, some objects do not need to be allocated, such as:
> 
> 
> class Formatter {
>     public Formatter format(Locale l, String format, Object ... args) {
>     	List<FormatString> fsa = parse(format);
>     	// ...
>     }
> 
>     static List<FormatString> parse(String s) {
>     	ArrayList<FormatString> al = new ArrayList<>();
> 
>         while (i < max) {
>             int n = s.indexOf('%', i);
>             if (n < 0) {
>                 // 
>                 al.add(new FixedString(s, i, max));
>             }
>         }
>     }
> }
> 
> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List<FormatString> fsa` to store it.
> 
> ## 2. Fast path print
> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method.
> 
> ## 3. String.format directly calls j.u.Formatter
> String.format directly calls j.u.Formatter via SharedSecrets to improve performance

The performance improvement in most scenarios is very significant.

The performance of complexFormat/decimalFormat scenes has decreased because the inline root has changed. I have a solution and will submit it after this PR is completed. The content is these two commits:

[split print decimal](https://github.com/wenshao/jdk/commit/e3a6fe17912b5c17901e1518e74c9ab9a7e0057f)

[refactor parser](https://github.com/wenshao/jdk/commit/0cc63265062d1480bc31e9010f91e83bc7d911f3)

Performance numbers under MacBook M1 Pro


make test TEST="micro:java.lang.StringFormat"



# baseline 982e3f0e14dd4e5d0d13c6c0fe49903a555f5f5e
-Benchmark                               Mode  Cnt    Score    Error  Units
-StringFormat.complexFormat              avgt   15  944.745 ? 70.806  ns/op
-StringFormat.decimalFormat              avgt   15  285.709 ? 14.579  ns/op
-StringFormat.intFormat                  avgt   15   60.176 ?  1.258  ns/op
-StringFormat.intFormatUtf16             avgt   15  124.083 ?  3.547  ns/op
-StringFormat.intHexFormat               avgt   15  251.195 ? 68.026  ns/op
-StringFormat.intHexFormatUtf16          avgt   15  126.030 ? 14.631  ns/op
-StringFormat.intHexUFormat              avgt   15  201.430 ?  7.106  ns/op
-StringFormat.intHexUFormatUtf16         avgt   15  137.988 ? 13.681  ns/op
-StringFormat.intIntFormat               avgt   15  131.670 ?  6.723  ns/op
-StringFormat.intIntFormatUtf16          avgt   15  127.279 ?  2.857  ns/op
-StringFormat.intOctalFormat             avgt   15  248.651 ? 67.083  ns/op
-StringFormat.intOctalFormatUtf16        avgt   15  115.897 ?  2.131  ns/op
-StringFormat.lineFormatUtf16            avgt   15  143.465 ? 12.187  ns/op
-StringFormat.lineFormat                 avgt   15   59.753 ?  0.598  ns/op
-StringFormat.stringFormat               avgt   15   62.188 ?  2.317  ns/op
-StringFormat.stringFormatUtf16          avgt   15  158.438 ?  8.377  ns/op
-StringFormat.stringIntFormat            avgt   15  123.869 ?  4.107  ns/op
-StringFormat.stringIntFormatUtf16       avgt   15  173.503 ? 19.792  ns/op
-StringFormat.stringIntHexFormat         avgt   15  156.958 ?  6.641  ns/op
-StringFormat.stringIntHexUFormat        avgt   15  163.373 ?  9.474  ns/op
-StringFormat.stringIntOctalFormat       avgt   15  157.360 ?  6.569  ns/op
-StringFormat.stringIntOctalFormatUtf16  avgt   15  147.697 ?  6.050  ns/op
-StringFormat.stringIntRFormat           avgt   15  137.308 ?  7.921  ns/op
-StringFormat.stringIntRFormatUtf16      avgt   15  199.334 ?  6.728  ns/op
-StringFormat.stringWidthIntFormat       avgt   15  148.663 ?  3.549  ns/op
-StringFormat.stringWidthIntFormatUtf16  avgt   15  138.486 ?  3.704  ns/op
-StringFormat.widthStringFormat          avgt   15   94.476 ? 21.884  ns/op
-StringFormat.widthStringFormatUtf16     avgt   15  130.753 ?  3.555  ns/op
-StringFormat.widthStringIntFormat       avgt   15  153.143 ?  9.967  ns/op
-StringFormat.widthStringIntFormatUtf16  avgt   15  162.539 ?  6.323  ns/op

# current 5d866bf17d96bd0f0e4545d7eee5912eda2e3a94
+Benchmark                               Mode  Cnt     Score    Error  Units
+StringFormat.complexFormat              avgt   15  1008.713 ? 86.458  ns/op
+StringFormat.decimalFormat              avgt   15   386.167 ? 76.843  ns/op
+StringFormat.intFormat                  avgt   15    19.628 ?  0.076  ns/op
+StringFormat.intFormatUtf16             avgt   15    25.678 ?  0.224  ns/op
+StringFormat.intHexFormat               avgt   15   106.220 ? 31.809  ns/op
+StringFormat.intHexFormatUtf16          avgt   15   104.698 ?  7.862  ns/op
+StringFormat.intHexUFormat              avgt   15    99.228 ?  5.523  ns/op
+StringFormat.intHexUFormatUtf16         avgt   15    73.016 ?  5.311  ns/op
+StringFormat.intIntFormat               avgt   15    86.851 ?  3.479  ns/op
+StringFormat.intIntFormatUtf16          avgt   15    88.352 ?  4.553  ns/op
+StringFormat.intOctalFormat             avgt   15   176.610 ? 38.408  ns/op
+StringFormat.intOctalFormatUtf16        avgt   15    69.189 ?  1.362  ns/op
+StringFormat.lineFormat                 avgt   15    20.554 ?  0.044  ns/op
+StringFormat.lineFormatUtf16            avgt   15    45.253 ? 29.207  ns/op
+StringFormat.stringFormat               avgt   15    19.869 ?  0.073  ns/op
+StringFormat.stringFormatUtf16          avgt   15    25.119 ?  0.065  ns/op
+StringFormat.stringIntFormat            avgt   15    87.287 ?  2.808  ns/op
+StringFormat.stringIntFormatUtf16       avgt   15    76.377 ?  5.036  ns/op
+StringFormat.stringIntHexFormat         avgt   15   109.946 ? 53.831  ns/op
+StringFormat.stringIntHexUFormat        avgt   15   117.475 ? 55.030  ns/op
+StringFormat.stringIntOctalFormat       avgt   15   109.248 ?  5.347  ns/op
+StringFormat.stringIntOctalFormatUtf16  avgt   15   167.115 ? 25.219  ns/op
+StringFormat.stringIntRFormat           avgt   15    95.606 ?  8.299  ns/op
+StringFormat.stringIntRFormatUtf16      avgt   15    92.061 ? 17.822  ns/op
+StringFormat.stringWidthIntFormat       avgt   15    91.130 ?  5.954  ns/op
+StringFormat.stringWidthIntFormatUtf16  avgt   15   101.798 ?  7.317  ns/op
+StringFormat.widthStringFormat          avgt   15    20.644 ?  0.344  ns/op
+StringFormat.widthStringFormatUtf16     avgt   15    26.111 ?  0.228  ns/op
+StringFormat.widthStringIntFormat       avgt   15    79.138 ? 24.128  ns/op
+StringFormat.widthStringIntFormatUtf16  avgt   15    54.597 ?  1.191  ns/op


|   | baseline  | current | delta |
| --- | --- | --- | --- |
| StringFormat.complexFormat | 944.745 | 1008.713 | -6.34% |
| StringFormat.decimalFormat | 285.709 | 386.167 | -26.01% |
| StringFormat.intFormat | 60.176 | 19.628 | 206.58% |
| StringFormat.intFormatUtf16 | 124.083 | 25.678 | 383.23% |
| StringFormat.intHexFormat | 251.195 | 106.220 | 136.49% |
| StringFormat.intHexFormatUtf16 | 126.030 | 104.698 | 20.37% |
| StringFormat.intHexUFormat | 201.430 | 99.228 | 103.00% |
| StringFormat.intHexUFormatUtf16 | 137.988 | 73.016 | 88.98% |
| StringFormat.intIntFormat | 131.670 | 86.851 | 51.60% |
| StringFormat.intIntFormatUtf16 | 127.279 | 88.352 | 44.06% |
| StringFormat.intOctalFormat | 248.651 | 176.610 | 40.79% |
| StringFormat.intOctalFormatUtf16 | 115.897 | 69.189 | 67.51% |
| StringFormat.lineFormatUtf16 | 143.465 | 45.253 | 217.03% |
| StringFormat.lineFormat | 59.753 | 20.554 | 190.71% |
| StringFormat.stringFormat | 62.188 | 19.869 | 212.99% |
| StringFormat.stringFormatUtf16 | 158.438 | 25.119 | 530.75% |
| StringFormat.stringIntFormat | 123.869 | 87.287 | 41.91% |
| StringFormat.stringIntFormatUtf16 | 173.503 | 76.377 | 127.17% |
| StringFormat.stringIntHexFormat | 156.958 | 109.946 | 42.76% |
| StringFormat.stringIntHexUFormat | 163.373 | 117.475 | 39.07% |
| StringFormat.stringIntOctalFormat | 157.360 | 109.248 | 44.04% |
| StringFormat.stringIntOctalFormatUtf16 | 147.697 | 167.115 | -11.62% |
| StringFormat.stringIntRFormat | 137.308 | 95.606 | 43.62% |
| StringFormat.stringIntRFormatUtf16 | 199.334 | 92.061 | 116.52% |
| StringFormat.stringWidthIntFormat | 148.663 | 91.130 | 63.13% |
| StringFormat.stringWidthIntFormatUtf16 | 138.486 | 101.798 | 36.04% |
| StringFormat.widthStringFormat | 94.476 | 20.644 | 357.64% |
| StringFormat.widthStringFormatUtf16 | 130.753 | 26.111 | 400.76% |
| StringFormat.widthStringIntFormat | 153.143 | 79.138 | 93.51% |
| StringFormat.widthStringIntFormatUtf16 | 162.539 | 54.597 | 197.71% |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20055#issuecomment-2211096061

From liach at openjdk.org  Fri Jul  5 20:00:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 Jul 2024 20:00:36 GMT
Subject: <i18n dev> =?utf-8?b?UkZSOiA4MzM1NzkxOiBTcGVlZCDigIvigIt1cCBq?=
 =?utf-8?q?=2Eu=2EFormatter_=26_String=2Eformat?=
In-Reply-To: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
References: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
Message-ID: <gSLPdn25TK9I_yvE7wqyY2MqPhDaPzThI-bALXfGSvI=.f82cccc0-d3f9-4bc3-8f1b-a97cdf02028a@github.com>

On Fri, 5 Jul 2024 15:40:24 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently.
> 
> 
> Improved performance includes the following:
> 
> ## 1. Write directly during the parse process to reduce object allocation.
> 
> In the current Formatter implementation, some objects do not need to be allocated, such as:
> 
> 
> class Formatter {
>     public Formatter format(Locale l, String format, Object ... args) {
>     	List<FormatString> fsa = parse(format);
>     	// ...
>     }
> 
>     static List<FormatString> parse(String s) {
>     	ArrayList<FormatString> al = new ArrayList<>();
> 
>         while (i < max) {
>             int n = s.indexOf('%', i);
>             if (n < 0) {
>                 // 
>                 al.add(new FixedString(s, i, max));
>             }
>         }
>     }
> }
> 
> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List<FormatString> fsa` to store it.
> 
> ## 2. Fast path print
> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method.
> 
> ## 3. String.format directly calls j.u.Formatter
> String.format directly calls j.u.Formatter via SharedSecrets to improve performance

src/java.base/share/classes/java/lang/String.java line 4548:

> 4546:     }
> 4547: 
> 4548:     private static class StringFormat {

Since we want to avoid new classes on startup, we should change the lazy initialization pattern to:


private static @Stable JavaUtilFormatterAccess jufa;
private static JavaUtilFormatterAccess formatterAccess() {
    var access = jufa;
    if (access = null) {
        // We can assert not null on the getJUFA result
        return jufa = SharedSecrets.getJavaUtilFormatterAccess();
    }
    return access;
}

using benign race.

src/java.base/share/classes/java/util/Formatter.java line 3107:

> 3105:                 if (fmt.locale() != l)
> 3106:                     fmt = new Formatter(fmt.out(), l);
> 3107:                 ((Formattable)arg).formatTo(fmt, Flags.NONE, -1, -1);

You can use pattern matching for instanceof to avoid a cast here.

src/java.base/share/classes/java/util/Formatter.java line 5260:

> 5258:         }
> 5259: 
> 5260:         static final FormatString[] specifiers = new FormatString[128];

Suggestion:

        static final @Stable FormatString[] specifiers = new FormatString[128];

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20055#discussion_r1667064117
PR Review Comment: https://git.openjdk.org/jdk/pull/20055#discussion_r1667087769
PR Review Comment: https://git.openjdk.org/jdk/pull/20055#discussion_r1667091143

From duke at openjdk.org  Fri Jul  5 20:30:50 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 5 Jul 2024 20:30:50 GMT
Subject: <i18n dev> =?utf-8?b?UkZSOiA4MzM1NzkxOiBTcGVlZCDigIvigIt1cCBq?=
 =?utf-8?b?LnUuRm9ybWF0dGVyICYgU3RyaW5nLmZvcm1hdCBbdjJd?=
In-Reply-To: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
References: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
Message-ID: <dx5J6jQ0YMW1UJwtDeegqtzCoaTCyQP9AYFGBTxB9Us=.8d439607-204e-4b44-8468-c89a71e2bbf0@github.com>

> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently.
> 
> 
> Improved performance includes the following:
> 
> ## 1. Write directly during the parse process to reduce object allocation.
> 
> In the current Formatter implementation, some objects do not need to be allocated, such as:
> 
> 
> class Formatter {
>     public Formatter format(Locale l, String format, Object ... args) {
>     	List<FormatString> fsa = parse(format);
>     	// ...
>     }
> 
>     static List<FormatString> parse(String s) {
>     	ArrayList<FormatString> al = new ArrayList<>();
> 
>         while (i < max) {
>             int n = s.indexOf('%', i);
>             if (n < 0) {
>                 // 
>                 al.add(new FixedString(s, i, max));
>             }
>         }
>     }
> }
> 
> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List<FormatString> fsa` to store it.
> 
> ## 2. Fast path print
> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method.
> 
> ## 3. String.format directly calls j.u.Formatter
> String.format directly calls j.u.Formatter via SharedSecrets to improve performance

Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:

 - use unknownFormatConversion method construct UnknownFormatConversionException
 - uppercase static final field name & code format
 - add stable annotation
 - replace cast to pattern matching

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20055/files
  - new: https://git.openjdk.org/jdk/pull/20055/files/982e3f0e..27ff0b5d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=00-01

  Stats: 26 lines in 1 file changed: 1 ins; 5 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/20055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20055/head:pull/20055

PR: https://git.openjdk.org/jdk/pull/20055

From duke at openjdk.org  Fri Jul  5 20:36:33 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 5 Jul 2024 20:36:33 GMT
Subject: <i18n dev> =?utf-8?b?UkZSOiA4MzM1NzkxOiBTcGVlZCDigIvigIt1cCBq?=
 =?utf-8?b?LnUuRm9ybWF0dGVyICYgU3RyaW5nLmZvcm1hdCBbdjJd?=
In-Reply-To: <gSLPdn25TK9I_yvE7wqyY2MqPhDaPzThI-bALXfGSvI=.f82cccc0-d3f9-4bc3-8f1b-a97cdf02028a@github.com>
References: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
 <gSLPdn25TK9I_yvE7wqyY2MqPhDaPzThI-bALXfGSvI=.f82cccc0-d3f9-4bc3-8f1b-a97cdf02028a@github.com>
Message-ID: <fNi9LuEL3hVxZqakIScSgABzj5x1F9w3RTycWFHzcOs=.6253a7ba-f0a8-4fcb-bd8c-b587be95b5ce@github.com>

On Fri, 5 Jul 2024 18:56:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - use unknownFormatConversion method construct UnknownFormatConversionException
>>  - uppercase static final field name & code format
>>  - add stable annotation
>>  - replace cast to pattern matching
>
> src/java.base/share/classes/java/lang/String.java line 4548:
> 
>> 4546:     }
>> 4547: 
>> 4548:     private static class StringFormat {
> 
> Since we want to avoid new classes on startup, we should change the lazy initialization pattern to:
> 
> 
> private static @Stable JavaUtilFormatterAccess jufa;
> private static JavaUtilFormatterAccess formatterAccess() {
>     var access = jufa;
>     if (access = null) {
>         // We can assert not null on the getJUFA result
>         return jufa = SharedSecrets.getJavaUtilFormatterAccess();
>     }
>     return access;
> }
> 
> using benign race.

I found out through `-verbose:class` that StringFormat is not in the class loaded by startup

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20055#discussion_r1667120045

From duke at openjdk.org  Fri Jul  5 20:43:51 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 5 Jul 2024 20:43:51 GMT
Subject: <i18n dev> =?utf-8?b?UkZSOiA4MzM1NzkxOiBTcGVlZCDigIvigIt1cCBq?=
 =?utf-8?b?LnUuRm9ybWF0dGVyICYgU3RyaW5nLmZvcm1hdCBbdjNd?=
In-Reply-To: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
References: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
Message-ID: <ehQLItU1hg7OlJCFaq3Ue50ipksqngDc3trQp_Qk5QU=.41fe5156-a6c6-4d06-a98f-f310865592c3@github.com>

> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently.
> 
> 
> Improved performance includes the following:
> 
> ## 1. Write directly during the parse process to reduce object allocation.
> 
> In the current Formatter implementation, some objects do not need to be allocated, such as:
> 
> 
> class Formatter {
>     public Formatter format(Locale l, String format, Object ... args) {
>     	List<FormatString> fsa = parse(format);
>     	// ...
>     }
> 
>     static List<FormatString> parse(String s) {
>     	ArrayList<FormatString> al = new ArrayList<>();
> 
>         while (i < max) {
>             int n = s.indexOf('%', i);
>             if (n < 0) {
>                 // 
>                 al.add(new FixedString(s, i, max));
>             }
>         }
>     }
> }
> 
> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List<FormatString> fsa` to store it.
> 
> ## 2. Fast path print
> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method.
> 
> ## 3. String.format directly calls j.u.Formatter
> String.format directly calls j.u.Formatter via SharedSecrets to improve performance

Shaojin Wen 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 six additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into optim_str_format_202407
 - use unknownFormatConversion method construct UnknownFormatConversionException
 - uppercase static final field name & code format
 - add stable annotation
 - replace cast to pattern matching
 - speed up j.u.Formatter & String.format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20055/files
  - new: https://git.openjdk.org/jdk/pull/20055/files/27ff0b5d..b2f517ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=01-02

  Stats: 8510 lines in 385 files changed: 5009 ins; 1904 del; 1597 mod
  Patch: https://git.openjdk.org/jdk/pull/20055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20055/head:pull/20055

PR: https://git.openjdk.org/jdk/pull/20055

From liach at openjdk.org  Fri Jul  5 20:48:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 Jul 2024 20:48:33 GMT
Subject: <i18n dev> =?utf-8?b?UkZSOiA4MzM1NzkxOiBTcGVlZCDigIvigIt1cCBq?=
 =?utf-8?b?LnUuRm9ybWF0dGVyICYgU3RyaW5nLmZvcm1hdCBbdjNd?=
In-Reply-To: <ehQLItU1hg7OlJCFaq3Ue50ipksqngDc3trQp_Qk5QU=.41fe5156-a6c6-4d06-a98f-f310865592c3@github.com>
References: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
 <ehQLItU1hg7OlJCFaq3Ue50ipksqngDc3trQp_Qk5QU=.41fe5156-a6c6-4d06-a98f-f310865592c3@github.com>
Message-ID: <YNxTGsR6QOKuQyAmj5AiaV2qNHR4V8oZelPXyEt8G9c=.dfdd00c1-0334-4115-87ea-abe115bec949@github.com>

On Fri, 5 Jul 2024 20:43:51 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently.
>> 
>> 
>> Improved performance includes the following:
>> 
>> ## 1. Write directly during the parse process to reduce object allocation.
>> 
>> In the current Formatter implementation, some objects do not need to be allocated, such as:
>> 
>> 
>> class Formatter {
>>     public Formatter format(Locale l, String format, Object ... args) {
>>     	List<FormatString> fsa = parse(format);
>>     	// ...
>>     }
>> 
>>     static List<FormatString> parse(String s) {
>>     	ArrayList<FormatString> al = new ArrayList<>();
>> 
>>         while (i < max) {
>>             int n = s.indexOf('%', i);
>>             if (n < 0) {
>>                 // 
>>                 al.add(new FixedString(s, i, max));
>>             }
>>         }
>>     }
>> }
>> 
>> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List<FormatString> fsa` to store it.
>> 
>> ## 2. Fast path print
>> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method.
>> 
>> ## 3. String.format directly calls j.u.Formatter
>> String.format directly calls j.u.Formatter via SharedSecrets to improve performance
>
> Shaojin Wen 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 six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_str_format_202407
>  - use unknownFormatConversion method construct UnknownFormatConversionException
>  - uppercase static final field name & code format
>  - add stable annotation
>  - replace cast to pattern matching
>  - speed up j.u.Formatter & String.format

About `decimalFormat` performance drop: can you add the `@CompilerControl(CompilerControl.Mode.DONT_INLINE)` annotation on the benchmark class (or the methods), and show the performance results before and after? You can run the test selection as `StringFormat.(complex|decimal)Format` to just run the 2 tests with regressions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20055#issuecomment-2211394922

From duke at openjdk.org  Fri Jul  5 22:02:38 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 5 Jul 2024 22:02:38 GMT
Subject: <i18n dev> =?utf-8?b?UkZSOiA4MzM1NzkxOiBTcGVlZCDigIvigIt1cCBq?=
 =?utf-8?b?LnUuRm9ybWF0dGVyICYgU3RyaW5nLmZvcm1hdCBbdjNd?=
In-Reply-To: <ehQLItU1hg7OlJCFaq3Ue50ipksqngDc3trQp_Qk5QU=.41fe5156-a6c6-4d06-a98f-f310865592c3@github.com>
References: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
 <ehQLItU1hg7OlJCFaq3Ue50ipksqngDc3trQp_Qk5QU=.41fe5156-a6c6-4d06-a98f-f310865592c3@github.com>
Message-ID: <3qXcv6JoJCBL75nvQVcKTzV3X9Uf_VAMVIvOPq3Y324=.47298c9c-ccd8-43f1-86df-76414bd596a0@github.com>

On Fri, 5 Jul 2024 20:43:51 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently.
>> 
>> 
>> Improved performance includes the following:
>> 
>> ## 1. Write directly during the parse process to reduce object allocation.
>> 
>> In the current Formatter implementation, some objects do not need to be allocated, such as:
>> 
>> 
>> class Formatter {
>>     public Formatter format(Locale l, String format, Object ... args) {
>>     	List<FormatString> fsa = parse(format);
>>     	// ...
>>     }
>> 
>>     static List<FormatString> parse(String s) {
>>     	ArrayList<FormatString> al = new ArrayList<>();
>> 
>>         while (i < max) {
>>             int n = s.indexOf('%', i);
>>             if (n < 0) {
>>                 // 
>>                 al.add(new FixedString(s, i, max));
>>             }
>>         }
>>     }
>> }
>> 
>> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List<FormatString> fsa` to store it.
>> 
>> ## 2. Fast path print
>> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method.
>> 
>> ## 3. String.format directly calls j.u.Formatter
>> String.format directly calls j.u.Formatter via SharedSecrets to improve performance
>
> Shaojin Wen 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 six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_str_format_202407
>  - use unknownFormatConversion method construct UnknownFormatConversionException
>  - uppercase static final field name & code format
>  - add stable annotation
>  - replace cast to pattern matching
>  - speed up j.u.Formatter & String.format

The performance of the current version of decimalFormat is sometimes fast and sometimes slow. I don't know why.


make test TEST="micro:java.lang.StringFormat.decimalFormat"

# Benchmark: org.openjdk.bench.java.lang.StringFormat.decimalFormat

# Run progress: 0.00% complete, ETA 00:00:30
# Fork: 1 of 3
# Warmup Iteration   1: 438.502 ns/op
# Warmup Iteration   2: 473.917 ns/op
# Warmup Iteration   3: 468.569 ns/op
# Warmup Iteration   4: 411.787 ns/op
# Warmup Iteration   5: 417.982 ns/op
Iteration   1: 436.206 ns/op
Iteration   2: 422.356 ns/op
Iteration   3: 462.962 ns/op
Iteration   4: 408.021 ns/op
Iteration   5: 452.836 ns/op

# Run progress: 33.33% complete, ETA 00:00:22
# Fork: 2 of 3
# Warmup Iteration   1: 256.982 ns/op
# Warmup Iteration   2: 358.474 ns/op
# Warmup Iteration   3: 345.280 ns/op
# Warmup Iteration   4: 332.602 ns/op
# Warmup Iteration   5: 511.648 ns/op
Iteration   1: 478.953 ns/op
Iteration   2: 328.587 ns/op
Iteration   3: 195.851 ns/op
Iteration   4: 223.552 ns/op
Iteration   5: 228.569 ns/op

# Run progress: 66.67% complete, ETA 00:00:10
# Fork: 3 of 3
# Warmup Iteration   1: 446.023 ns/op
# Warmup Iteration   2: 360.855 ns/op
# Warmup Iteration   3: 540.793 ns/op
# Warmup Iteration   4: 537.336 ns/op
# Warmup Iteration   5: 248.511 ns/op
Iteration   1: 525.644 ns/op
Iteration   2: 463.829 ns/op
Iteration   3: 603.220 ns/op
Iteration   4: 248.151 ns/op
Iteration   5: 579.492 ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20055#issuecomment-2211455189

From duke at openjdk.org  Sat Jul  6 00:15:04 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 6 Jul 2024 00:15:04 GMT
Subject: <i18n dev> =?utf-8?b?UkZSOiA4MzM1NzkxOiBTcGVlZCDigIvigIt1cCBq?=
 =?utf-8?b?LnUuRm9ybWF0dGVyICYgU3RyaW5nLmZvcm1hdCBbdjRd?=
In-Reply-To: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
References: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
Message-ID: <hGJeZFind-4U7DFNVShiFE0xDqSvikSH_SXt9aBRhXc=.05cc29eb-d01b-4481-aeac-28f68b89579c@github.com>

> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently.
> 
> 
> Improved performance includes the following:
> 
> ## 1. Write directly during the parse process to reduce object allocation.
> 
> In the current Formatter implementation, some objects do not need to be allocated, such as:
> 
> 
> class Formatter {
>     public Formatter format(Locale l, String format, Object ... args) {
>     	List<FormatString> fsa = parse(format);
>     	// ...
>     }
> 
>     static List<FormatString> parse(String s) {
>     	ArrayList<FormatString> al = new ArrayList<>();
> 
>         while (i < max) {
>             int n = s.indexOf('%', i);
>             if (n < 0) {
>                 // 
>                 al.add(new FixedString(s, i, max));
>             }
>         }
>     }
> }
> 
> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List<FormatString> fsa` to store it.
> 
> ## 2. Fast path print
> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method.
> 
> ## 3. String.format directly calls j.u.Formatter
> String.format directly calls j.u.Formatter via SharedSecrets to improve performance

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Implementing JavaUtilFormatterAccess using anonymous class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20055/files
  - new: https://git.openjdk.org/jdk/pull/20055/files/b2f517ba..129d7eba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=02-03

  Stats: 11 lines in 1 file changed: 1 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20055/head:pull/20055

PR: https://git.openjdk.org/jdk/pull/20055

From duke at openjdk.org  Sat Jul  6 00:54:35 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 6 Jul 2024 00:54:35 GMT
Subject: <i18n dev> =?utf-8?b?UkZSOiA4MzM1NzkxOiBTcGVlZCDigIvigIt1cCBq?=
 =?utf-8?b?LnUuRm9ybWF0dGVyICYgU3RyaW5nLmZvcm1hdCBbdjRd?=
In-Reply-To: <hGJeZFind-4U7DFNVShiFE0xDqSvikSH_SXt9aBRhXc=.05cc29eb-d01b-4481-aeac-28f68b89579c@github.com>
References: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
 <hGJeZFind-4U7DFNVShiFE0xDqSvikSH_SXt9aBRhXc=.05cc29eb-d01b-4481-aeac-28f68b89579c@github.com>
Message-ID: <4yj2y5WSZQOgMeBWIKAwfALpmHeE_AldK0HUGw86_Yg=.0500f80e-5bba-4c82-8904-6111f8fe88c9@github.com>

On Sat, 6 Jul 2024 00:15:04 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently.
>> 
>> 
>> Improved performance includes the following:
>> 
>> ## 1. Write directly during the parse process to reduce object allocation.
>> 
>> In the current Formatter implementation, some objects do not need to be allocated, such as:
>> 
>> 
>> class Formatter {
>>     public Formatter format(Locale l, String format, Object ... args) {
>>     	List<FormatString> fsa = parse(format);
>>     	// ...
>>     }
>> 
>>     static List<FormatString> parse(String s) {
>>     	ArrayList<FormatString> al = new ArrayList<>();
>> 
>>         while (i < max) {
>>             int n = s.indexOf('%', i);
>>             if (n < 0) {
>>                 // 
>>                 al.add(new FixedString(s, i, max));
>>             }
>>         }
>>     }
>> }
>> 
>> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List<FormatString> fsa` to store it.
>> 
>> ## 2. Fast path print
>> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method.
>> 
>> ## 3. String.format directly calls j.u.Formatter
>> String.format directly calls j.u.Formatter via SharedSecrets to improve performance
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implementing JavaUtilFormatterAccess using anonymous class

The performance degradation of decimalFormat only occurred on the MacBook M1, and it did not occur when I tested it on the cloud host.

## [Aliyun ecs.c8a](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8a)
* CPU AMD EPYCTM Genoa
* Platform x64

# baseline b83766e59063a41ea8801ac9e7c15dce67727c62
-Benchmark                               Mode  Cnt    Score    Error  Units
-StringFormat.complexFormat              avgt   15  590.667 ? 17.059  ns/op
-StringFormat.decimalFormat              avgt   15  293.412 ?  2.359  ns/op
-StringFormat.intFormat                  avgt   15   66.778 ?  0.865  ns/op
-StringFormat.intFormatUtf16             avgt   15   69.233 ?  0.090  ns/op
-StringFormat.intHexFormat               avgt   15  116.871 ?  0.783  ns/op
-StringFormat.intHexFormatUtf16          avgt   15  130.486 ?  0.749  ns/op
-StringFormat.intHexUFormat              avgt   15  122.547 ?  0.952  ns/op
-StringFormat.intHexUFormatUtf16         avgt   15  133.570 ?  2.035  ns/op
-StringFormat.intIntFormat               avgt   15  118.463 ?  2.773  ns/op
-StringFormat.intIntFormatUtf16          avgt   15  120.305 ?  0.973  ns/op
-StringFormat.intOctalFormat             avgt   15  117.049 ?  1.190  ns/op
-StringFormat.intOctalFormatUtf16        avgt   15  131.041 ?  2.719  ns/op
-StringFormat.lineFormat                 avgt   15   46.440 ?  0.355  ns/op
-StringFormat.lineFormatUtf16            avgt   15   51.169 ?  0.308  ns/op
-StringFormat.stringFormat               avgt   15   50.507 ?  1.189  ns/op
-StringFormat.stringFormatUtf16          avgt   15   54.684 ?  0.136  ns/op
-StringFormat.stringIntFormat            avgt   15  107.311 ?  0.719  ns/op
-StringFormat.stringIntFormatUtf16       avgt   15  115.677 ?  2.801  ns/op
-StringFormat.stringIntHexFormat         avgt   15  103.388 ?  0.585  ns/op
-StringFormat.stringIntHexUFormat        avgt   15  103.773 ?  0.215  ns/op
-StringFormat.stringIntOctalFormat       avgt   15  103.900 ?  0.931  ns/op
-StringFormat.stringIntOctalFormatUtf16  avgt   15  116.362 ?  1.118  ns/op
-StringFormat.stringIntRFormat           avgt   15  127.924 ?  0.122  ns/op
-StringFormat.stringIntRFormatUtf16      avgt   15  142.177 ?  3.507  ns/op
-StringFormat.stringWidthIntFormat       avgt   15  142.864 ?  2.229  ns/op
-StringFormat.stringWidthIntFormatUtf16  avgt   15  141.588 ?  0.745  ns/op
-StringFormat.widthStringFormat          avgt   15   62.167 ?  0.439  ns/op
-StringFormat.widthStringFormatUtf16     avgt   15   67.403 ?  0.804  ns/op
-StringFormat.widthStringIntFormat       avgt   15  136.524 ?  0.521  ns/op
-StringFormat.widthStringIntFormatUtf16  avgt   15  138.060 ?  2.828  ns/op

# current b2f517ba459c55b2d69fe5a43723d15370cdab4b
+Benchmark                               Mode  Cnt    Score    Error  Units
+StringFormat.complexFormat              avgt   15  412.950 ? 26.777  ns/op
+StringFormat.decimalFormat              avgt   15  260.532 ?  2.942  ns/op
+StringFormat.intFormat                  avgt   15   24.184 ?  1.125  ns/op
+StringFormat.intFormatUtf16             avgt   15   27.183 ?  0.151  ns/op
+StringFormat.intHexFormat               avgt   15   55.386 ?  0.344  ns/op
+StringFormat.intHexFormatUtf16          avgt   15   70.344 ?  1.067  ns/op
+StringFormat.intHexUFormat              avgt   15   61.599 ?  2.133  ns/op
+StringFormat.intHexUFormatUtf16         avgt   15   80.965 ?  6.596  ns/op
+StringFormat.intIntFormat               avgt   15   53.510 ?  0.804  ns/op
+StringFormat.intIntFormatUtf16          avgt   15   53.795 ?  0.289  ns/op
+StringFormat.intOctalFormat             avgt   15   65.075 ?  0.526  ns/op
+StringFormat.intOctalFormatUtf16        avgt   15   79.609 ?  2.225  ns/op
+StringFormat.lineFormat                 avgt   15   24.306 ?  0.061  ns/op
+StringFormat.lineFormatUtf16            avgt   15   28.136 ?  0.133  ns/op
+StringFormat.stringFormat               avgt   15   24.137 ?  0.159  ns/op
+StringFormat.stringFormatUtf16          avgt   15   28.368 ?  0.065  ns/op
+StringFormat.stringIntFormat            avgt   15   50.953 ?  0.121  ns/op
+StringFormat.stringIntFormatUtf16       avgt   15   62.363 ?  0.501  ns/op
+StringFormat.stringIntHexFormat         avgt   15   59.528 ?  0.199  ns/op
+StringFormat.stringIntHexUFormat        avgt   15   58.935 ?  0.515  ns/op
+StringFormat.stringIntOctalFormat       avgt   15   68.614 ?  0.140  ns/op
+StringFormat.stringIntOctalFormatUtf16  avgt   15   80.326 ?  1.014  ns/op
+StringFormat.stringIntRFormat           avgt   15   60.547 ?  0.743  ns/op
+StringFormat.stringIntRFormatUtf16      avgt   15   76.189 ?  3.493  ns/op
+StringFormat.stringWidthIntFormat       avgt   15   57.070 ?  0.616  ns/op
+StringFormat.stringWidthIntFormatUtf16  avgt   15   68.253 ?  0.288  ns/op
+StringFormat.widthStringFormat          avgt   15   24.473 ?  0.251  ns/op
+StringFormat.widthStringFormatUtf16     avgt   15   29.436 ?  0.050  ns/op
+StringFormat.widthStringIntFormat       avgt   15   57.610 ?  0.535  ns/op
+StringFormat.widthStringIntFormatUtf16  avgt   15   65.597 ?  1.587  ns/op


|   | baseline  | current | delta |
| --- | --- | --- | --- |
| StringFormat.complexFormat | 590.667 | 412.950 | 43.04% |
| StringFormat.decimalFormat | 293.412 | 260.532 | 12.62% |
| StringFormat.intFormat | 66.778 | 24.184 | 176.12% |
| StringFormat.intFormatUtf16 | 69.233 | 27.183 | 154.69% |
| StringFormat.intHexFormat | 116.871 | 55.386 | 111.01% |
| StringFormat.intHexFormatUtf16 | 130.486 | 70.344 | 85.50% |
| StringFormat.intHexUFormat | 122.547 | 61.599 | 98.94% |
| StringFormat.intHexUFormatUtf16 | 133.570 | 80.965 | 64.97% |
| StringFormat.intIntFormat | 118.463 | 53.510 | 121.38% |
| StringFormat.intIntFormatUtf16 | 120.305 | 53.795 | 123.64% |
| StringFormat.intOctalFormat | 117.049 | 65.075 | 79.87% |
| StringFormat.intOctalFormatUtf16 | 131.041 | 79.609 | 64.61% |
| StringFormat.lineFormat | 46.440 | 24.306 | 91.06% |
| StringFormat.lineFormatUtf16 | 51.169 | 28.136 | 81.86% |
| StringFormat.stringFormat | 50.507 | 24.137 | 109.25% |
| StringFormat.stringFormatUtf16 | 54.684 | 28.368 | 92.77% |
| StringFormat.stringIntFormat | 107.311 | 50.953 | 110.61% |
| StringFormat.stringIntFormatUtf16 | 115.677 | 62.363 | 85.49% |
| StringFormat.stringIntHexFormat | 103.388 | 59.528 | 73.68% |
| StringFormat.stringIntHexUFormat | 103.773 | 58.935 | 76.08% |
| StringFormat.stringIntOctalFormat | 103.900 | 68.614 | 51.43% |
| StringFormat.stringIntOctalFormatUtf16 | 116.362 | 80.326 | 44.86% |
| StringFormat.stringIntRFormat | 127.924 | 60.547 | 111.28% |
| StringFormat.stringIntRFormatUtf16 | 142.177 | 76.189 | 86.61% |
| StringFormat.stringWidthIntFormat | 142.864 | 57.070 | 150.33% |
| StringFormat.stringWidthIntFormatUtf16 | 141.588 | 68.253 | 107.45% |
| StringFormat.widthStringFormat | 62.167 | 24.473 | 154.02% |
| StringFormat.widthStringFormatUtf16 | 67.403 | 29.436 | 128.98% |
| StringFormat.widthStringIntFormat | 136.524 | 57.610 | 136.98% |
| StringFormat.widthStringIntFormatUtf16 | 138.060 | 65.597 | 110.47% |



## [aliyun ecs.c8i](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i)
* CPU Intel? Xeon? Emerald
* Platform x64


# baseline b83766e59063a41ea8801ac9e7c15dce67727c62
-Benchmark                               Mode  Cnt    Score   Error  Units
-StringFormat.complexFormat              avgt   15  529.057 ? 4.446  ns/op
-StringFormat.decimalFormat              avgt   15  322.432 ? 1.405  ns/op
-StringFormat.intFormat                  avgt   15   65.234 ? 0.220  ns/op
-StringFormat.intFormatUtf16             avgt   15   70.822 ? 0.907  ns/op
-StringFormat.intHexFormat               avgt   15  108.173 ? 0.526  ns/op
-StringFormat.intHexFormatUtf16          avgt   15  123.867 ? 0.686  ns/op
-StringFormat.intHexUFormat              avgt   15  112.425 ? 0.841  ns/op
-StringFormat.intHexUFormatUtf16         avgt   15  128.555 ? 1.833  ns/op
-StringFormat.intIntFormat               avgt   15  117.720 ? 1.043  ns/op
-StringFormat.intIntFormatUtf16          avgt   15  119.817 ? 1.976  ns/op
-StringFormat.intOctalFormat             avgt   15  108.340 ? 0.417  ns/op
-StringFormat.intOctalFormatUtf16        avgt   15  121.281 ? 2.423  ns/op
-StringFormat.lineFormat                 avgt   15   46.437 ? 0.146  ns/op
-StringFormat.lineFormatUtf16            avgt   15   52.059 ? 0.268  ns/op
-StringFormat.stringFormat               avgt   15   48.699 ? 0.266  ns/op
-StringFormat.stringFormatUtf16          avgt   15   55.069 ? 0.295  ns/op
-StringFormat.stringIntFormat            avgt   15   97.408 ? 0.855  ns/op
-StringFormat.stringIntFormatUtf16       avgt   15  113.801 ? 1.206  ns/op
-StringFormat.stringIntHexFormat         avgt   15   95.091 ? 0.540  ns/op
-StringFormat.stringIntHexUFormat        avgt   15   94.368 ? 0.389  ns/op
-StringFormat.stringIntOctalFormat       avgt   15   94.731 ? 0.592  ns/op
-StringFormat.stringIntOctalFormatUtf16  avgt   15  107.460 ? 0.100  ns/op
-StringFormat.stringIntRFormat           avgt   15  114.745 ? 0.211  ns/op
-StringFormat.stringIntRFormatUtf16      avgt   15  132.979 ? 3.001  ns/op
-StringFormat.stringWidthIntFormat       avgt   15  129.590 ? 0.719  ns/op
-StringFormat.stringWidthIntFormatUtf16  avgt   15  134.643 ? 2.166  ns/op
-StringFormat.widthStringFormat          avgt   15   60.557 ? 0.716  ns/op
-StringFormat.widthStringFormatUtf16     avgt   15   67.925 ? 0.798  ns/op
-StringFormat.widthStringIntFormat       avgt   15  125.359 ? 1.424  ns/op
-StringFormat.widthStringIntFormatUtf16  avgt   15  131.336 ? 1.519  ns/op

# current b2f517ba459c55b2d69fe5a43723d15370cdab4b
+Benchmark                               Mode  Cnt    Score   Error  Units
+StringFormat.complexFormat              avgt   15  386.754 ? 7.144  ns/op
+StringFormat.decimalFormat              avgt   15  289.619 ? 2.738  ns/op
+StringFormat.intFormat                  avgt   15   25.465 ? 2.249  ns/op
+StringFormat.intFormatUtf16             avgt   15   31.938 ? 1.428  ns/op
+StringFormat.intHexFormat               avgt   15   51.730 ? 1.685  ns/op
+StringFormat.intHexFormatUtf16          avgt   15   71.242 ? 1.330  ns/op
+StringFormat.intHexUFormat              avgt   15   57.009 ? 0.636  ns/op
+StringFormat.intHexUFormatUtf16         avgt   15   75.337 ? 0.378  ns/op
+StringFormat.intIntFormat               avgt   15   52.773 ? 0.163  ns/op
+StringFormat.intIntFormatUtf16          avgt   15   52.769 ? 0.131  ns/op
+StringFormat.intOctalFormat             avgt   15   58.615 ? 0.456  ns/op
+StringFormat.intOctalFormatUtf16        avgt   15   75.639 ? 0.689  ns/op
+StringFormat.lineFormat                 avgt   15   23.287 ? 0.093  ns/op
+StringFormat.lineFormatUtf16            avgt   15   30.649 ? 0.150  ns/op
+StringFormat.stringFormat               avgt   15   22.710 ? 0.055  ns/op
+StringFormat.stringFormatUtf16          avgt   15   30.146 ? 0.114  ns/op
+StringFormat.stringIntFormat            avgt   15   50.326 ? 0.122  ns/op
+StringFormat.stringIntFormatUtf16       avgt   15   62.278 ? 1.169  ns/op
+StringFormat.stringIntHexFormat         avgt   15   56.447 ? 0.280  ns/op
+StringFormat.stringIntHexUFormat        avgt   15   56.390 ? 0.641  ns/op
+StringFormat.stringIntOctalFormat       avgt   15   67.885 ? 0.603  ns/op
+StringFormat.stringIntOctalFormatUtf16  avgt   15   78.597 ? 1.861  ns/op
+StringFormat.stringIntRFormat           avgt   15   56.320 ? 0.581  ns/op
+StringFormat.stringIntRFormatUtf16      avgt   15   75.227 ? 2.130  ns/op
+StringFormat.stringWidthIntFormat       avgt   15   54.156 ? 0.110  ns/op
+StringFormat.stringWidthIntFormatUtf16  avgt   15   68.158 ? 2.946  ns/op
+StringFormat.widthStringFormat          avgt   15   23.148 ? 0.150  ns/op
+StringFormat.widthStringFormatUtf16     avgt   15   31.589 ? 0.283  ns/op
+StringFormat.widthStringIntFormat       avgt   15   57.852 ? 0.495  ns/op
+StringFormat.widthStringIntFormatUtf16  avgt   15   69.162 ? 2.344  ns/op


|   | baseline  | current | delta |
| --- | --- | --- | --- |
| StringFormat.complexFormat | 529.057 | 386.754 | 36.79% |
| StringFormat.decimalFormat | 322.432 | 289.619 | 11.33% |
| StringFormat.intFormat | 65.234 | 25.465 | 156.17% |
| StringFormat.intFormatUtf16 | 70.822 | 31.938 | 121.75% |
| StringFormat.intHexFormat | 108.173 | 51.730 | 109.11% |
| StringFormat.intHexFormatUtf16 | 123.867 | 71.242 | 73.87% |
| StringFormat.intHexUFormat | 112.425 | 57.009 | 97.21% |
| StringFormat.intHexUFormatUtf16 | 128.555 | 75.337 | 70.64% |
| StringFormat.intIntFormat | 117.720 | 52.773 | 123.07% |
| StringFormat.intIntFormatUtf16 | 119.817 | 52.769 | 127.06% |
| StringFormat.intOctalFormat | 108.340 | 58.615 | 84.83% |
| StringFormat.intOctalFormatUtf16 | 121.281 | 75.639 | 60.34% |
| StringFormat.lineFormat | 46.437 | 23.287 | 99.41% |
| StringFormat.lineFormatUtf16 | 52.059 | 30.649 | 69.86% |
| StringFormat.stringFormat | 48.699 | 22.710 | 114.44% |
| StringFormat.stringFormatUtf16 | 55.069 | 30.146 | 82.67% |
| StringFormat.stringIntFormat | 97.408 | 50.326 | 93.55% |
| StringFormat.stringIntFormatUtf16 | 113.801 | 62.278 | 82.73% |
| StringFormat.stringIntHexFormat | 95.091 | 56.447 | 68.46% |
| StringFormat.stringIntHexUFormat | 94.368 | 56.390 | 67.35% |
| StringFormat.stringIntOctalFormat | 94.731 | 67.885 | 39.55% |
| StringFormat.stringIntOctalFormatUtf16 | 107.460 | 78.597 | 36.72% |
| StringFormat.stringIntRFormat | 114.745 | 56.320 | 103.74% |
| StringFormat.stringIntRFormatUtf16 | 132.979 | 75.227 | 76.77% |
| StringFormat.stringWidthIntFormat | 129.590 | 54.156 | 139.29% |
| StringFormat.stringWidthIntFormatUtf16 | 134.643 | 68.158 | 97.55% |
| StringFormat.widthStringFormat | 60.557 | 23.148 | 161.61% |
| StringFormat.widthStringFormatUtf16 | 67.925 | 31.589 | 115.03% |
| StringFormat.widthStringIntFormat | 125.359 | 57.852 | 116.69% |
| StringFormat.widthStringIntFormatUtf16 | 131.336 | 69.162 | 89.90% |


## [aliyun ecs.c8y](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8y)
* CPU Yitian710 aarch64
* Platform aarch64


# baseline b83766e59063a41ea8801ac9e7c15dce67727c62
-Benchmark                               Mode  Cnt    Score    Error  Units
-StringFormat.complexFormat              avgt   15  773.031 ?  3.099  ns/op
-StringFormat.decimalFormat              avgt   15  398.171 ?  4.713  ns/op
-StringFormat.intFormat                  avgt   15  103.018 ?  2.348  ns/op
-StringFormat.intFormatUtf16             avgt   15  119.492 ?  2.190  ns/op
-StringFormat.intHexFormat               avgt   15  177.283 ?  3.302  ns/op
-StringFormat.intHexFormatUtf16          avgt   15  195.128 ?  9.053  ns/op
-StringFormat.intHexUFormat              avgt   15  194.399 ?  7.280  ns/op
-StringFormat.intHexUFormatUtf16         avgt   15  200.689 ?  4.014  ns/op
-StringFormat.intIntFormat               avgt   15  180.146 ?  1.970  ns/op
-StringFormat.intIntFormatUtf16          avgt   15  195.222 ? 13.176  ns/op
-StringFormat.intOctalFormat             avgt   15  174.285 ?  8.477  ns/op
-StringFormat.intOctalFormatUtf16        avgt   15  186.157 ?  3.778  ns/op
-StringFormat.lineFormat                 avgt   15   82.938 ?  0.863  ns/op
-StringFormat.lineFormatUtf16            avgt   15   94.125 ?  0.790  ns/op
-StringFormat.stringFormat               avgt   15   81.651 ?  4.897  ns/op
-StringFormat.stringFormatUtf16          avgt   15   98.348 ?  0.773  ns/op
-StringFormat.stringIntFormat            avgt   15  167.333 ?  1.800  ns/op
-StringFormat.stringIntFormatUtf16       avgt   15  190.981 ?  4.937  ns/op
-StringFormat.stringIntHexFormat         avgt   15  157.498 ?  3.696  ns/op
-StringFormat.stringIntHexUFormat        avgt   15  160.588 ?  3.764  ns/op
-StringFormat.stringIntOctalFormat       avgt   15  160.813 ?  2.398  ns/op
-StringFormat.stringIntOctalFormatUtf16  avgt   15  176.153 ?  7.430  ns/op
-StringFormat.stringIntRFormat           avgt   15  187.924 ?  0.902  ns/op
-StringFormat.stringIntRFormatUtf16      avgt   15  202.559 ?  2.601  ns/op
-StringFormat.stringWidthIntFormat       avgt   15  194.698 ?  4.673  ns/op
-StringFormat.stringWidthIntFormatUtf16  avgt   15  233.417 ?  5.496  ns/op
-StringFormat.widthStringFormat          avgt   15  100.334 ?  0.915  ns/op
-StringFormat.widthStringFormatUtf16     avgt   15  113.190 ? 13.681  ns/op
-StringFormat.widthStringIntFormat       avgt   15  211.096 ?  1.347  ns/op
-StringFormat.widthStringIntFormatUtf16  avgt   15  227.000 ? 10.045  ns/op

# current b2f517ba459c55b2d69fe5a43723d15370cdab4b
+Benchmark                               Mode  Cnt    Score    Error  Units
+StringFormat.complexFormat              avgt   15  581.514 ? 13.122  ns/op
+StringFormat.decimalFormat              avgt   15  348.420 ?  1.901  ns/op
+StringFormat.intFormat                  avgt   15   29.603 ?  0.325  ns/op
+StringFormat.intFormatUtf16             avgt   15   35.211 ?  0.459  ns/op
+StringFormat.intHexFormat               avgt   15   68.486 ?  0.894  ns/op
+StringFormat.intHexFormatUtf16          avgt   15   94.581 ?  8.873  ns/op
+StringFormat.intHexUFormat              avgt   15   77.773 ?  1.939  ns/op
+StringFormat.intHexUFormatUtf16         avgt   15   95.887 ?  1.966  ns/op
+StringFormat.intIntFormat               avgt   15   70.615 ?  1.438  ns/op
+StringFormat.intIntFormatUtf16          avgt   15   66.945 ?  2.027  ns/op
+StringFormat.intOctalFormat             avgt   15   80.453 ?  1.638  ns/op
+StringFormat.intOctalFormatUtf16        avgt   15  102.267 ?  3.882  ns/op
+StringFormat.lineFormat                 avgt   15   29.769 ?  0.634  ns/op
+StringFormat.lineFormatUtf16            avgt   15   35.713 ?  1.031  ns/op
+StringFormat.stringFormat               avgt   15   28.574 ?  0.458  ns/op
+StringFormat.stringFormatUtf16          avgt   15   35.554 ?  0.496  ns/op
+StringFormat.stringIntFormat            avgt   15   62.198 ?  3.217  ns/op
+StringFormat.stringIntFormatUtf16       avgt   15   89.910 ?  3.620  ns/op
+StringFormat.stringIntHexFormat         avgt   15   67.230 ?  1.309  ns/op
+StringFormat.stringIntHexUFormat        avgt   15   66.143 ?  1.140  ns/op
+StringFormat.stringIntOctalFormat       avgt   15   78.613 ?  1.046  ns/op
+StringFormat.stringIntOctalFormatUtf16  avgt   15  104.297 ?  4.769  ns/op
+StringFormat.stringIntRFormat           avgt   15   67.872 ?  1.229  ns/op
+StringFormat.stringIntRFormatUtf16      avgt   15   93.982 ?  1.778  ns/op
+StringFormat.stringWidthIntFormat       avgt   15   70.326 ?  3.684  ns/op
+StringFormat.stringWidthIntFormatUtf16  avgt   15   88.422 ?  5.396  ns/op
+StringFormat.widthStringFormat          avgt   15   28.349 ?  0.462  ns/op
+StringFormat.widthStringFormatUtf16     avgt   15   35.467 ?  0.370  ns/op
+StringFormat.widthStringIntFormat       avgt   15   68.397 ?  3.443  ns/op
+StringFormat.widthStringIntFormatUtf16  avgt   15   86.467 ?  3.557  ns/op


|   | baseline  | current | delta |
| --- | --- | --- | --- |
| StringFormat.complexFormat | 773.031 | 581.514 | 32.93% |
| StringFormat.decimalFormat | 398.171 | 348.420 | 14.28% |
| StringFormat.intFormat | 103.018 | 29.603 | 248.00% |
| StringFormat.intFormatUtf16 | 119.492 | 35.211 | 239.36% |
| StringFormat.intHexFormat | 177.283 | 68.486 | 158.86% |
| StringFormat.intHexFormatUtf16 | 195.128 | 94.581 | 106.31% |
| StringFormat.intHexUFormat | 194.399 | 77.773 | 149.96% |
| StringFormat.intHexUFormatUtf16 | 200.689 | 95.887 | 109.30% |
| StringFormat.intIntFormat | 180.146 | 70.615 | 155.11% |
| StringFormat.intIntFormatUtf16 | 195.222 | 66.945 | 191.62% |
| StringFormat.intOctalFormat | 174.285 | 80.453 | 116.63% |
| StringFormat.intOctalFormatUtf16 | 186.157 | 102.267 | 82.03% |
| StringFormat.lineFormat | 82.938 | 29.769 | 178.61% |
| StringFormat.lineFormatUtf16 | 94.125 | 35.713 | 163.56% |
| StringFormat.stringFormat | 81.651 | 28.574 | 185.75% |
| StringFormat.stringFormatUtf16 | 98.348 | 35.554 | 176.62% |
| StringFormat.stringIntFormat | 167.333 | 62.198 | 169.03% |
| StringFormat.stringIntFormatUtf16 | 190.981 | 89.910 | 112.41% |
| StringFormat.stringIntHexFormat | 157.498 | 67.230 | 134.27% |
| StringFormat.stringIntHexUFormat | 160.588 | 66.143 | 142.79% |
| StringFormat.stringIntOctalFormat | 160.813 | 78.613 | 104.56% |
| StringFormat.stringIntOctalFormatUtf16 | 176.153 | 104.297 | 68.90% |
| StringFormat.stringIntRFormat | 187.924 | 67.872 | 176.88% |
| StringFormat.stringIntRFormatUtf16 | 202.559 | 93.982 | 115.53% |
| StringFormat.stringWidthIntFormat | 194.698 | 70.326 | 176.85% |
| StringFormat.stringWidthIntFormatUtf16 | 233.417 | 88.422 | 163.98% |
| StringFormat.widthStringFormat | 100.334 | 28.349 | 253.92% |
| StringFormat.widthStringFormatUtf16 | 113.190 | 35.467 | 219.14% |
| StringFormat.widthStringIntFormat | 211.096 | 68.397 | 208.63% |
| StringFormat.widthStringIntFormatUtf16 | 227.000 | 86.467 | 162.53% |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20055#issuecomment-2211548388

From duke at openjdk.org  Mon Jul  8 02:32:17 2024
From: duke at openjdk.org (lingjun-cg)
Date: Mon, 8 Jul 2024 02:32:17 GMT
Subject: <i18n dev> RFR: 8333396: Performance regression of
 DecimalFormat.format [v17]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <HPksZxRtyhvMHKYbyAWum4kTrZzo45woJR5H59ZNdko=.ddecc6f8-0ae6-4193-956b-cc04b0672f53@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Performance regression of DecimalFormat.format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/7122c2c8..d675bcbf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=15-16

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From liach at openjdk.org  Mon Jul  8 03:08:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Jul 2024 03:08:44 GMT
Subject: <i18n dev> RFR: 8333396: Performance regression of
 DecimalFormat.format [v17]
In-Reply-To: <HPksZxRtyhvMHKYbyAWum4kTrZzo45woJR5H59ZNdko=.ddecc6f8-0ae6-4193-956b-cc04b0672f53@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <HPksZxRtyhvMHKYbyAWum4kTrZzo45woJR5H59ZNdko=.ddecc6f8-0ae6-4193-956b-cc04b0672f53@github.com>
Message-ID: <72jz9brO1nItDKitOCrcGYQMiEv4GKKfMUQvASiVH4c=.903656b2-bb11-40b3-b1a5-fe472d729a22@github.com>

On Mon, 8 Jul 2024 02:32:17 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

Quick question about the violation of the "This is equivalent to" spec: Does our new implementation lead to any observable side effects that make the returned results or thrown exceptions different from that of `format(obj, new StringBuffer(), new FieldPosition(0)).toString()`?

In the ClassFile API, there are similar "behave as if" notes such as https://github.com/openjdk/jdk/blob/3f37c5718d676b7001e6a084aed3ba645745a144/src/java.base/share/classes/java/lang/classfile/ClassFile.java#L433-L438, yet we don't restrict implementations as the API surface, including the return an exception result and side effects are the same.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2212893099

From duke at openjdk.org  Mon Jul  8 03:51:36 2024
From: duke at openjdk.org (lingjun-cg)
Date: Mon, 8 Jul 2024 03:51:36 GMT
Subject: <i18n dev> RFR: 8333396: Performance regression of
 DecimalFormat.format [v16]
In-Reply-To: <VEcg_aqYyXOsLN91r-PxnP4rUaORGcegHYlzmQLuiCE=.6bc10d29-77bb-4dee-9fac-49a393d3f042@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9axU7oSSiv3hbiHb71VynRC-RSn6iKmW8EWhGFpyvlA=.57cf9880-ac37-4591-80bd-0439b1144351@github.com>
 <VEcg_aqYyXOsLN91r-PxnP4rUaORGcegHYlzmQLuiCE=.6bc10d29-77bb-4dee-9fac-49a393d3f042@github.com>
Message-ID: <VHRnhJotQTxtnE7xfZWfyXSdAhT6WHQLk0lYz6clYAA=.880cf500-f87b-45a8-9fc0-363d68d62adc@github.com>

On Fri, 5 Jul 2024 16:54:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Following up on my previous comment regarding the _untrue wording_.
> 
> I no longer think we can just split the implementation and specification portion of this PR into two issues, since if we backport the implementation only, the specification would now be violated for the back-ported releases. We may have to just include the specification in this issue as well, (which will require a CSR and no longer means we can backport this change).

A CSR request created: https://bugs.openjdk.org/browse/JDK-8335834

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2212946822

From naoto at openjdk.org  Mon Jul  8 16:33:36 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 8 Jul 2024 16:33:36 GMT
Subject: <i18n dev> RFR: 8333396: Performance regression of
 DecimalFormat.format [v17]
In-Reply-To: <72jz9brO1nItDKitOCrcGYQMiEv4GKKfMUQvASiVH4c=.903656b2-bb11-40b3-b1a5-fe472d729a22@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <HPksZxRtyhvMHKYbyAWum4kTrZzo45woJR5H59ZNdko=.ddecc6f8-0ae6-4193-956b-cc04b0672f53@github.com>
 <72jz9brO1nItDKitOCrcGYQMiEv4GKKfMUQvASiVH4c=.903656b2-bb11-40b3-b1a5-fe472d729a22@github.com>
Message-ID: <Z1OetiJVJ1gFLlGmmff0JIpfGcldTWJZPj7Uy2ToLEg=.a9c14938-095c-43e0-8a62-c071023171e1@github.com>

On Mon, 8 Jul 2024 03:06:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> Quick question about the violation of the "This is equivalent to" spec: Does our new implementation lead to any observable side effects that make the returned results or thrown exceptions different from that of `format(obj, new StringBuffer(), new FieldPosition(0)).toString()`?
> 
> In the ClassFile API, there are similar "behave as if" notes such as
> 
> https://github.com/openjdk/jdk/blob/3f37c5718d676b7001e6a084aed3ba645745a144/src/java.base/share/classes/java/lang/classfile/ClassFile.java#L433-L438
> 
> , yet we don't restrict implementations as the API surface, including the return an exception result and side effects are the same.

AFAIK, there will be no behavioral difference, but I think CSR has to be accompanied with this issue to remove that wording, because it is not correct anymore.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2214627225

From jlu at openjdk.org  Mon Jul  8 17:34:38 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 8 Jul 2024 17:34:38 GMT
Subject: <i18n dev> RFR: 8333396: Performance regression of
 DecimalFormat.format [v17]
In-Reply-To: <HPksZxRtyhvMHKYbyAWum4kTrZzo45woJR5H59ZNdko=.ddecc6f8-0ae6-4193-956b-cc04b0672f53@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <HPksZxRtyhvMHKYbyAWum4kTrZzo45woJR5H59ZNdko=.ddecc6f8-0ae6-4193-956b-cc04b0672f53@github.com>
Message-ID: <XlvCkdW1WujIq3rffyoetdOk24xSsAgih6ZAbtwbtZE=.ff72699b-ac73-4bcd-87cf-e5e22a63e773@github.com>

On Mon, 8 Jul 2024 02:32:17 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

I believe the `static MessageFormat.format(...` also has similar incorrect "this is equivalent ..." wording, if you could please include that as well. I think we should also rename the issue (and CSR) as well since the scope has changed. Something along the lines of "Use StringBuilder internally for java.text.Format.* formatting".

-------------

Changes requested by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2163963773

From duke at openjdk.org  Tue Jul  9 02:06:34 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 9 Jul 2024 02:06:34 GMT
Subject: <i18n dev> RFR: 8333396: Use StringBuilder internally for
 java.text.Format.* formatting [v18]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <kuCM2fnOZXDk9bQImWdwR1qMsbe2A2JzJhidHe9w3D0=.9b95bb0f-2ab6-4ea8-9af4-0e9634514ceb@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Use StringBuilder internally for java.text.Format.* formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/d675bcbf..5fda8747

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=16-17

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From duke at openjdk.org  Tue Jul  9 02:37:42 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 9 Jul 2024 02:37:42 GMT
Subject: <i18n dev> RFR: 8333396: Use StringBuilder internally for
 java.text.Format.* formatting [v17]
In-Reply-To: <XlvCkdW1WujIq3rffyoetdOk24xSsAgih6ZAbtwbtZE=.ff72699b-ac73-4bcd-87cf-e5e22a63e773@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <HPksZxRtyhvMHKYbyAWum4kTrZzo45woJR5H59ZNdko=.ddecc6f8-0ae6-4193-956b-cc04b0672f53@github.com>
 <XlvCkdW1WujIq3rffyoetdOk24xSsAgih6ZAbtwbtZE=.ff72699b-ac73-4bcd-87cf-e5e22a63e773@github.com>
Message-ID: <OFXOsAfTCWbpMUClD4Ks84dU486T5fsi6gP0hlhjXS4=.d2e07e80-3413-421d-b536-4c80279c88eb@github.com>

On Mon, 8 Jul 2024 17:31:53 GMT, Justin Lu <jlu at openjdk.org> wrote:

> I believe the `static MessageFormat.format(...` also has similar incorrect "this is equivalent ..." wording, if you could please include that as well. I think we should also rename the issue (and CSR) as well since the scope has changed. Something along the lines of "Use StringBuilder internally for java.text.Format.* formatting".

Thanks for checking carefully. Updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2216286724

From jlu at openjdk.org  Tue Jul  9 18:41:24 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 9 Jul 2024 18:41:24 GMT
Subject: <i18n dev> RFR: 8333396: Use StringBuilder internally for
 java.text.Format.* formatting [v18]
In-Reply-To: <kuCM2fnOZXDk9bQImWdwR1qMsbe2A2JzJhidHe9w3D0=.9b95bb0f-2ab6-4ea8-9af4-0e9634514ceb@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <kuCM2fnOZXDk9bQImWdwR1qMsbe2A2JzJhidHe9w3D0=.9b95bb0f-2ab6-4ea8-9af4-0e9634514ceb@github.com>
Message-ID: <HSKOsnacMA4vwr5ph3SSfYPCXu-dbh6d4BPih3ncfiw=.5ae46fdc-02d4-4612-ab5a-f421312de621@github.com>

On Tue, 9 Jul 2024 02:06:34 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Use StringBuilder internally for java.text.Format.* formatting

Thanks for the changes. Let's work to get the CSR in good shape now.

(I have left comments directly on the CSR).

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2167093930

From jlu at openjdk.org  Tue Jul  9 18:49:44 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 9 Jul 2024 18:49:44 GMT
Subject: <i18n dev> RFR: 8335668: NumberFormat integer only parsing should
 throw exception for edge case
Message-ID: <PHp_SyD3ObyjeOP732gue6EUAJK6sDOfqtymwYYFUEw=.dd6e4fe5-2162-4141-a657-66c259cd5d4b@github.com>

Please review this PR which corrects a case in NumberFormat integer only parsing.

[JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer only parsing when the value has a suffix, although it caused incorrect behavior for the following case: when the parsed string does not contain an integer portion, and the format has integer only parsing, parsing should fail, instead of 0 being returned. For example, 


var fmt = NumberFormat.getIntegerInstance();
fmt.parse(".5", new ParsePosition(0)); // should return null, not 0


The changes to the _badParseStrings_ data provider in _StrictParseTest.java_ are needed since those cases _should_ fail in different indexes depending on if integer parsing is enabled. Thus, they were updated to ensure they fail for both integer and non-integer parsing with the same errorIndex.

In the fix itself, I also updated the initial value of `intIndex` to -1 from 0, to provide better clarity.

-------------

Commit messages:
 - clean up + add more general test cases
 - init

Changes: https://git.openjdk.org/jdk/pull/20101/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20101&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335668
  Stats: 65 lines in 3 files changed: 54 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/20101.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20101/head:pull/20101

PR: https://git.openjdk.org/jdk/pull/20101

From naoto at openjdk.org  Tue Jul  9 19:46:18 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jul 2024 19:46:18 GMT
Subject: <i18n dev> RFR: 8335668: NumberFormat integer only parsing
 should throw exception for edge case
In-Reply-To: <PHp_SyD3ObyjeOP732gue6EUAJK6sDOfqtymwYYFUEw=.dd6e4fe5-2162-4141-a657-66c259cd5d4b@github.com>
References: <PHp_SyD3ObyjeOP732gue6EUAJK6sDOfqtymwYYFUEw=.dd6e4fe5-2162-4141-a657-66c259cd5d4b@github.com>
Message-ID: <Dxkp_q28BKEse_l0hOxEirsNwlxzaowLttWJ2-mL3nw=.bfb547c8-05d8-4481-b171-5b94bcf2f544@github.com>

On Tue, 9 Jul 2024 18:42:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which corrects a case in NumberFormat integer only parsing.
> 
> [JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer only parsing when the value has a suffix, although it caused incorrect behavior for the following case: when the parsed string does not contain an integer portion, and the format has integer only parsing, parsing should fail, instead of 0 being returned. For example, 
> 
> 
> var fmt = NumberFormat.getIntegerInstance();
> fmt.parse(".5", new ParsePosition(0)); // should return null, not 0
> 
> 
> The changes to the _badParseStrings_ data provider in _StrictParseTest.java_ are needed since those cases _should_ fail in different indexes depending on if integer parsing is enabled. Thus, they were updated to ensure they fail for both integer and non-integer parsing with the same errorIndex.
> 
> In the fix itself, I also updated the initial value of `intIndex` to -1 from 0, to provide better clarity.

The fix looks good. A couple of comments on tests.

test/jdk/java/text/Format/NumberFormat/LenientParseTest.java line 146:

> 144:     @EnabledIfSystemProperty(named = "user.language", matches = "en")
> 145:     public void compactIntegerParseOnlyFractionOnlyTest() {
> 146:         var fmt = NumberFormat.getIntegerInstance();

Should it get a compact number instance, instead of integer?

test/jdk/java/text/Format/NumberFormat/StrictParseTest.java line 221:

> 219:     @EnabledIfSystemProperty(named = "user.language", matches = "en")
> 220:     public void compactIntegerParseOnlyFractionOnlyTest() {
> 221:         var fmt = NumberFormat.getIntegerInstance();

same here

-------------

PR Review: https://git.openjdk.org/jdk/pull/20101#pullrequestreview-2167273474
PR Review Comment: https://git.openjdk.org/jdk/pull/20101#discussion_r1671085244
PR Review Comment: https://git.openjdk.org/jdk/pull/20101#discussion_r1671086182

From jlu at openjdk.org  Tue Jul  9 20:29:48 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 9 Jul 2024 20:29:48 GMT
Subject: <i18n dev> RFR: 8335668: NumberFormat integer only parsing
 should throw exception for edge case [v2]
In-Reply-To: <PHp_SyD3ObyjeOP732gue6EUAJK6sDOfqtymwYYFUEw=.dd6e4fe5-2162-4141-a657-66c259cd5d4b@github.com>
References: <PHp_SyD3ObyjeOP732gue6EUAJK6sDOfqtymwYYFUEw=.dd6e4fe5-2162-4141-a657-66c259cd5d4b@github.com>
Message-ID: <LJyoPJre510SBBW3K74iVdZ7Y8wXDCpAVZA-7mY1zMw=.2c9a3677-3774-49e4-9679-9989d9a12a04@github.com>

> Please review this PR which corrects a case in NumberFormat integer only parsing.
> 
> [JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer only parsing when the value has a suffix, although it caused incorrect behavior for the following case: when the parsed string does not contain an integer portion, and the format has integer only parsing, parsing should fail, instead of 0 being returned. For example, 
> 
> 
> var fmt = NumberFormat.getIntegerInstance();
> fmt.parse(".5", new ParsePosition(0)); // should return null, not 0
> 
> 
> The changes to the _badParseStrings_ data provider in _StrictParseTest.java_ are needed since those cases _should_ fail in different indexes depending on if integer parsing is enabled. Thus, they were updated to ensure they fail for both integer and non-integer parsing with the same errorIndex.
> 
> In the fix itself, I also updated the initial value of `intIndex` to -1 from 0, to provide better clarity.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20101/files
  - new: https://git.openjdk.org/jdk/pull/20101/files/522b8381..a11d3468

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20101&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20101&range=00-01

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20101.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20101/head:pull/20101

PR: https://git.openjdk.org/jdk/pull/20101

From jlu at openjdk.org  Tue Jul  9 20:29:48 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 9 Jul 2024 20:29:48 GMT
Subject: <i18n dev> RFR: 8335668: NumberFormat integer only parsing
 should throw exception for edge case [v2]
In-Reply-To: <Dxkp_q28BKEse_l0hOxEirsNwlxzaowLttWJ2-mL3nw=.bfb547c8-05d8-4481-b171-5b94bcf2f544@github.com>
References: <PHp_SyD3ObyjeOP732gue6EUAJK6sDOfqtymwYYFUEw=.dd6e4fe5-2162-4141-a657-66c259cd5d4b@github.com>
 <Dxkp_q28BKEse_l0hOxEirsNwlxzaowLttWJ2-mL3nw=.bfb547c8-05d8-4481-b171-5b94bcf2f544@github.com>
Message-ID: <H4ZY15IOvJmMrvD3mXAhQDXMrQLBONxeppuoZA3v7eM=.aff43fe3-3174-4401-abab-9b652acf9ebd@github.com>

On Tue, 9 Jul 2024 19:41:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect review
>
> test/jdk/java/text/Format/NumberFormat/LenientParseTest.java line 146:
> 
>> 144:     @EnabledIfSystemProperty(named = "user.language", matches = "en")
>> 145:     public void compactIntegerParseOnlyFractionOnlyTest() {
>> 146:         var fmt = NumberFormat.getIntegerInstance();
> 
> Should it get a compact number instance, instead of integer?

Thanks for catching, I would hope the compact test actually tests a compact format; fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20101#discussion_r1671197396

From duke at openjdk.org  Wed Jul 10 01:53:10 2024
From: duke at openjdk.org (lingjun-cg)
Date: Wed, 10 Jul 2024 01:53:10 GMT
Subject: <i18n dev> RFR: 8333396: Use StringBuilder internally for
 java.text.Format.* formatting [v19]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <BcbdUDI3i7AcNu5lZkEgXNGuZp1r1eOQlc9MCk-E-uE=.bd4db233-4fea-4435-8330-1c3a39871655@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Use StringBuilder internally for java.text.Format.* formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/5fda8747..6573e413

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=17-18

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From naoto at openjdk.org  Wed Jul 10 20:07:47 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jul 2024 20:07:47 GMT
Subject: <i18n dev> RFR: 8335668: NumberFormat integer only parsing
 should throw exception for edge case [v2]
In-Reply-To: <LJyoPJre510SBBW3K74iVdZ7Y8wXDCpAVZA-7mY1zMw=.2c9a3677-3774-49e4-9679-9989d9a12a04@github.com>
References: <PHp_SyD3ObyjeOP732gue6EUAJK6sDOfqtymwYYFUEw=.dd6e4fe5-2162-4141-a657-66c259cd5d4b@github.com>
 <LJyoPJre510SBBW3K74iVdZ7Y8wXDCpAVZA-7mY1zMw=.2c9a3677-3774-49e4-9679-9989d9a12a04@github.com>
Message-ID: <NuUAcaQ3JK93NMnQmP-TjZGHvIabt1JyjIm5oNO3wWA=.558f6d43-5931-4d83-a21f-13d9b10574dd@github.com>

On Tue, 9 Jul 2024 20:29:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which corrects a case in NumberFormat integer only parsing.
>> 
>> [JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer only parsing when the value has a suffix, although it caused incorrect behavior for the following case: when the parsed string does not contain an integer portion, and the format has integer only parsing, parsing should fail, instead of 0 being returned. For example, 
>> 
>> 
>> var fmt = NumberFormat.getIntegerInstance();
>> fmt.parse(".5", new ParsePosition(0)); // should return null, not 0
>> 
>> 
>> The changes to the _badParseStrings_ data provider in _StrictParseTest.java_ are needed since those cases _should_ fail in different indexes depending on if integer parsing is enabled. Thus, they were updated to ensure they fail for both integer and non-integer parsing with the same errorIndex.
>> 
>> In the fix itself, I also updated the initial value of `intIndex` to -1 from 0, to provide better clarity.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20101#pullrequestreview-2169730057

From jlu at openjdk.org  Wed Jul 10 21:52:20 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 10 Jul 2024 21:52:20 GMT
Subject: <i18n dev> [jdk23] RFR: 8334418: Update IANA Language Subtag
 Registry to Version 2024-06-14
Message-ID: <u2LQitSsGUQgzzg087lPew83RBVkSOpNI6etMN-UEas=.3fae2020-f80e-4aa1-b126-86395a764988@github.com>

Please review this PR, which is a backport of commit [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This updates the IANA subtag registry to version 2024-06-14.

-------------

Commit messages:
 - Backport 861aefcafacdc21459ef966307f52568e327fd49

Changes: https://git.openjdk.org/jdk/pull/20125/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20125&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334418
  Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20125/head:pull/20125

PR: https://git.openjdk.org/jdk/pull/20125

From naoto at openjdk.org  Wed Jul 10 21:56:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jul 2024 21:56:55 GMT
Subject: <i18n dev> [jdk23] RFR: 8334418: Update IANA Language Subtag
 Registry to Version 2024-06-14
In-Reply-To: <u2LQitSsGUQgzzg087lPew83RBVkSOpNI6etMN-UEas=.3fae2020-f80e-4aa1-b126-86395a764988@github.com>
References: <u2LQitSsGUQgzzg087lPew83RBVkSOpNI6etMN-UEas=.3fae2020-f80e-4aa1-b126-86395a764988@github.com>
Message-ID: <LqjMehq4fE1j24F9CNEWihN0aoo3qMO-kCaskHtfbss=.49161535-9511-4053-857c-3b2908b28f42@github.com>

On Wed, 10 Jul 2024 21:46:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which is a backport of commit [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This updates the IANA subtag registry to version 2024-06-14.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20125#pullrequestreview-2170443912

From srl at openjdk.org  Wed Jul 10 22:11:02 2024
From: srl at openjdk.org (Steven Loomis)
Date: Wed, 10 Jul 2024 22:11:02 GMT
Subject: <i18n dev> RFR: 8334653: ISO 4217 Amendment 177 Update [v3]
In-Reply-To: <PjfozyFSOSyW0-px2No9nWxI4rFLhwM8n3TT45m30yM=.880ca4bd-0fae-4d5d-a94f-358531805091@github.com>
References: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
 <KSDsUIl970pSl2VfYTNxdQsyKuJz1PwLF_6EzwBT0NU=.22532f56-6b92-469a-b1c3-223c35cd5192@github.com>
 <ZYSL4fjcvG21tvK2quHfyF_WlLoR4I2OD5-w3J9ctkc=.d4e9fe38-da0f-4be7-a901-e4156dd41f19@github.com>
 <-d44Rl_Lgf3-Jdn-BE5nu8eZ8oQujOD_GfbFaidWXos=.7b6511ac-29b4-4ddb-a489-a3b538c543f7@github.com>
 <db3oNirMQ-ofzu5XPjWDQ7VuyZl56l9h-K-fHDdm0Ag=.6d6d0e8e-4603-4181-8672-9609142c5052@github.com>
 <PjfozyFSOSyW0-px2No9nWxI4rFLhwM8n3TT45m30yM=.880ca4bd-0fae-4d5d-a94f-358531805091@github.com>
Message-ID: <FqjrF5AaxYkmLBGy_yTJW8KBetdoi0_OXMKTeN_D50Q=.ebf78cff-ca6f-4489-b6ac-8cb53e6d9393@github.com>

On Fri, 21 Jun 2024 01:58:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Out of curiosity, what's the rationale behind the currency name change from "Zimbabwe Dollar" (ISO 4217 definition) to "Zimbabwean Dollar"?

I'm not sure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19813#discussion_r1673107271

From jlu at openjdk.org  Wed Jul 10 22:16:13 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 10 Jul 2024 22:16:13 GMT
Subject: <i18n dev> [jdk23] RFR: 8334653: ISO 4217 Amendment 177 Update
Message-ID: <tnGlX8pfeN6haUdb3Gk89B4A84EK57vsXBdMezMkLyY=.4f7ad9fa-225b-49ad-9b30-417339b89e4f@github.com>

Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This change incorporates the ISO 4217 Amendment 177 Update.

-------------

Commit messages:
 - Backport 86b0cf259fb3cbe3a1973151148e5d36c6a99d91

Changes: https://git.openjdk.org/jdk/pull/20126/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20126&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334653
  Stats: 23 lines in 6 files changed: 3 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/20126.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20126/head:pull/20126

PR: https://git.openjdk.org/jdk/pull/20126

From naoto at openjdk.org  Wed Jul 10 22:16:13 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jul 2024 22:16:13 GMT
Subject: <i18n dev> [jdk23] RFR: 8334653: ISO 4217 Amendment 177 Update
In-Reply-To: <tnGlX8pfeN6haUdb3Gk89B4A84EK57vsXBdMezMkLyY=.4f7ad9fa-225b-49ad-9b30-417339b89e4f@github.com>
References: <tnGlX8pfeN6haUdb3Gk89B4A84EK57vsXBdMezMkLyY=.4f7ad9fa-225b-49ad-9b30-417339b89e4f@github.com>
Message-ID: <EHacUny8D2sFomvDbBwHtPgMyJF3FYFdmU_JSqwPqFs=.4681be20-0631-4c55-8965-9da4e539fcd8@github.com>

On Wed, 10 Jul 2024 22:08:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This change incorporates the ISO 4217 Amendment 177 Update.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20126#pullrequestreview-2170464176

From wxiao at openjdk.org  Thu Jul 11 13:25:56 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Thu, 11 Jul 2024 13:25:56 GMT
Subject: <i18n dev> [jdk23] RFR: 8334418: Update IANA Language Subtag
 Registry to Version 2024-06-14
In-Reply-To: <u2LQitSsGUQgzzg087lPew83RBVkSOpNI6etMN-UEas=.3fae2020-f80e-4aa1-b126-86395a764988@github.com>
References: <u2LQitSsGUQgzzg087lPew83RBVkSOpNI6etMN-UEas=.3fae2020-f80e-4aa1-b126-86395a764988@github.com>
Message-ID: <37TEpPA1pn28CwVcBy65eqnSvG2J2LmligBz9svA-4w=.3981738d-7812-48be-81e0-59d7ebf81a61@github.com>

On Wed, 10 Jul 2024 21:46:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which is a backport of commit [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This updates the IANA subtag registry to version 2024-06-14.

The change was merged into jdk23, see the commmit https://github.com/openjdk/jdk/pull/20125

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20125#issuecomment-2222931615

From iris at openjdk.org  Thu Jul 11 18:33:28 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 11 Jul 2024 18:33:28 GMT
Subject: <i18n dev> [jdk23] RFR: 8334653: ISO 4217 Amendment 177 Update
In-Reply-To: <tnGlX8pfeN6haUdb3Gk89B4A84EK57vsXBdMezMkLyY=.4f7ad9fa-225b-49ad-9b30-417339b89e4f@github.com>
References: <tnGlX8pfeN6haUdb3Gk89B4A84EK57vsXBdMezMkLyY=.4f7ad9fa-225b-49ad-9b30-417339b89e4f@github.com>
Message-ID: <be58Iqv6qkjWxdEK5TAL-Hpl3jhHvB80kWpdhJbEo_A=.ed5b7f30-5300-4995-ae9f-d3ff0d275a1f@github.com>

On Wed, 10 Jul 2024 22:08:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This change incorporates the ISO 4217 Amendment 177 Update.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20126#pullrequestreview-2172722556

From iris at openjdk.org  Thu Jul 11 18:43:02 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 11 Jul 2024 18:43:02 GMT
Subject: <i18n dev> [jdk23] RFR: 8334418: Update IANA Language Subtag
 Registry to Version 2024-06-14
In-Reply-To: <u2LQitSsGUQgzzg087lPew83RBVkSOpNI6etMN-UEas=.3fae2020-f80e-4aa1-b126-86395a764988@github.com>
References: <u2LQitSsGUQgzzg087lPew83RBVkSOpNI6etMN-UEas=.3fae2020-f80e-4aa1-b126-86395a764988@github.com>
Message-ID: <-5S7_MmoHm8iFJAHSn9gd3uUK1CV6117vka_JIKFJHo=.2ceedf92-864b-46bc-9a71-d6392acde75c@github.com>

On Wed, 10 Jul 2024 21:46:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which is a backport of commit [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This updates the IANA subtag registry to version 2024-06-14.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20125#pullrequestreview-2172753557

From jlu at openjdk.org  Thu Jul 11 18:44:05 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 Jul 2024 18:44:05 GMT
Subject: <i18n dev> Integrated: 8335668: NumberFormat integer only parsing
 should throw exception for edge case
In-Reply-To: <PHp_SyD3ObyjeOP732gue6EUAJK6sDOfqtymwYYFUEw=.dd6e4fe5-2162-4141-a657-66c259cd5d4b@github.com>
References: <PHp_SyD3ObyjeOP732gue6EUAJK6sDOfqtymwYYFUEw=.dd6e4fe5-2162-4141-a657-66c259cd5d4b@github.com>
Message-ID: <xJZbdzPRKJ3lqGKsqxXYBnYTX9_OiJw-gM0zpvp4Sic=.b74c8838-45e9-43cc-9c6e-d10ceedf1b30@github.com>

On Tue, 9 Jul 2024 18:42:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which corrects a case in NumberFormat integer only parsing.
> 
> [JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer only parsing when the value has a suffix, although it caused incorrect behavior for the following case: when the parsed string does not contain an integer portion, and the format has integer only parsing, parsing should fail, instead of 0 being returned. For example, 
> 
> 
> var fmt = NumberFormat.getIntegerInstance();
> fmt.parse(".5", new ParsePosition(0)); // should return null, not 0
> 
> 
> The changes to the _badParseStrings_ data provider in _StrictParseTest.java_ are needed since those cases _should_ fail in different indexes depending on if integer parsing is enabled. Thus, they were updated to ensure they fail for both integer and non-integer parsing with the same errorIndex.
> 
> In the fix itself, I also updated the initial value of `intIndex` to -1 from 0, to provide better clarity.

This pull request has now been integrated.

Changeset: 5100303c
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5100303c6c5e4224d2c41f90719139bb5f4e236e
Stats:     67 lines in 3 files changed: 56 ins; 0 del; 11 mod

8335668: NumberFormat integer only parsing should throw exception for edge case

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/20101

From aturbanov at openjdk.org  Fri Jul 12 12:11:02 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 12 Jul 2024 12:11:02 GMT
Subject: <i18n dev> [jdk23] RFR: 8334653: ISO 4217 Amendment 177 Update
In-Reply-To: <tnGlX8pfeN6haUdb3Gk89B4A84EK57vsXBdMezMkLyY=.4f7ad9fa-225b-49ad-9b30-417339b89e4f@github.com>
References: <tnGlX8pfeN6haUdb3Gk89B4A84EK57vsXBdMezMkLyY=.4f7ad9fa-225b-49ad-9b30-417339b89e4f@github.com>
Message-ID: <9miIlVD596DkRNWzvYSBcMX9cDV0JLRxn_QLRFsDDfo=.3f459a78-edf9-4126-9a35-85f8b9d3a1d2@github.com>

On Wed, 10 Jul 2024 22:08:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This message is kind of confusing. This PR is for `openjdk/jdk` repository too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20126#issuecomment-2225445985

From jlu at openjdk.org  Fri Jul 12 16:28:53 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Jul 2024 16:28:53 GMT
Subject: <i18n dev> [jdk23] RFR: 8334653: ISO 4217 Amendment 177 Update
In-Reply-To: <9miIlVD596DkRNWzvYSBcMX9cDV0JLRxn_QLRFsDDfo=.3f459a78-edf9-4126-9a35-85f8b9d3a1d2@github.com>
References: <tnGlX8pfeN6haUdb3Gk89B4A84EK57vsXBdMezMkLyY=.4f7ad9fa-225b-49ad-9b30-417339b89e4f@github.com>
 <9miIlVD596DkRNWzvYSBcMX9cDV0JLRxn_QLRFsDDfo=.3f459a78-edf9-4126-9a35-85f8b9d3a1d2@github.com>
Message-ID: <pdYMMhqRiySeVK2hGrMM1YMRHoz-_1bhYt0mnSOsKF4=.f2424463-3a22-4d50-8f5c-5adf0073877a@github.com>

On Fri, 12 Jul 2024 12:08:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) mainline branch.
>> 
>> This change incorporates the ISO 4217 Amendment 177 Update.
>
>>Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This message is kind of confusing. This PR is for `openjdk/jdk` repository too.

@turbanoff true, I adjusted the message to indicate the original commit is from mainline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20126#issuecomment-2225923927

From jlu at openjdk.org  Fri Jul 12 20:20:57 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Jul 2024 20:20:57 GMT
Subject: <i18n dev> [jdk23] Integrated: 8334418: Update IANA Language Subtag
 Registry to Version 2024-06-14
In-Reply-To: <u2LQitSsGUQgzzg087lPew83RBVkSOpNI6etMN-UEas=.3fae2020-f80e-4aa1-b126-86395a764988@github.com>
References: <u2LQitSsGUQgzzg087lPew83RBVkSOpNI6etMN-UEas=.3fae2020-f80e-4aa1-b126-86395a764988@github.com>
Message-ID: <8wZH9uSU9bbrYVQJXbVX7V0EM-7UoeVnA32qDXEnJys=.20589b51-9f2a-4686-9ae4-90211807ac25@github.com>

On Wed, 10 Jul 2024 21:46:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which is a backport of commit [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49) from the [openjdk/jdk](https://git.openjdk.org/jdk) mainline branch.
> 
> This updates the IANA subtag registry to version 2024-06-14.

This pull request has now been integrated.

Changeset: 0a9e3bfc
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a9e3bfc904911bc9b83a75fd6023575995e8c2b
Stats:     7 lines in 2 files changed: 4 ins; 0 del; 3 mod

8334418: Update IANA Language Subtag Registry to Version 2024-06-14

Reviewed-by: naoto, iris
Backport-of: 861aefcafacdc21459ef966307f52568e327fd49

-------------

PR: https://git.openjdk.org/jdk/pull/20125

From duke at openjdk.org  Fri Jul 12 23:59:16 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 12 Jul 2024 23:59:16 GMT
Subject: <i18n dev> RFR: 8317980: Optimization for Integer.parseInt and
 Long.parseLong
Message-ID: <tc-wIpp8PRgt_KxxoJ8LMiLTYFXA3yTZ-ypI4aK4ttM=.dd9adc4a-b350-41c4-ab21-eeb74ac0ba35@github.com>

Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method.

The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods.

-------------

Commit messages:
 - optimize parseInt & parseLong

Changes: https://git.openjdk.org/jdk/pull/20168/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20168&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317980
  Stats: 126 lines in 6 files changed: 56 ins; 36 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/20168.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20168/head:pull/20168

PR: https://git.openjdk.org/jdk/pull/20168

From duke at openjdk.org  Sat Jul 13 00:50:18 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 13 Jul 2024 00:50:18 GMT
Subject: <i18n dev> RFR: 8317980: Optimization for Integer.parseInt and
 Long.parseLong [v2]
In-Reply-To: <tc-wIpp8PRgt_KxxoJ8LMiLTYFXA3yTZ-ypI4aK4ttM=.dd9adc4a-b350-41c4-ab21-eeb74ac0ba35@github.com>
References: <tc-wIpp8PRgt_KxxoJ8LMiLTYFXA3yTZ-ypI4aK4ttM=.dd9adc4a-b350-41c4-ab21-eeb74ac0ba35@github.com>
Message-ID: <rGqTfS2h6uN1SJfgHLgLiaFOTu5DMGvEGErO06_Gvmk=.783ffe86-cee8-473b-8b9e-c47610d8f219@github.com>

> Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method.
> 
> The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Reduce changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20168/files
  - new: https://git.openjdk.org/jdk/pull/20168/files/d15e4ed6..e2cbf4a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20168&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20168&range=00-01

  Stats: 69 lines in 3 files changed: 26 ins; 24 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/20168.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20168/head:pull/20168

PR: https://git.openjdk.org/jdk/pull/20168

From duke at openjdk.org  Sat Jul 13 02:51:57 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 13 Jul 2024 02:51:57 GMT
Subject: <i18n dev> RFR: 8317980: Optimization for Integer.parseInt and
 Long.parseLong [v2]
In-Reply-To: <rGqTfS2h6uN1SJfgHLgLiaFOTu5DMGvEGErO06_Gvmk=.783ffe86-cee8-473b-8b9e-c47610d8f219@github.com>
References: <tc-wIpp8PRgt_KxxoJ8LMiLTYFXA3yTZ-ypI4aK4ttM=.dd9adc4a-b350-41c4-ab21-eeb74ac0ba35@github.com>
 <rGqTfS2h6uN1SJfgHLgLiaFOTu5DMGvEGErO06_Gvmk=.783ffe86-cee8-473b-8b9e-c47610d8f219@github.com>
Message-ID: <SsoHENlYktDqMTbaUd0L_AK95ATzpXZX3p3lQ9_vsZI=.3981b56b-70cc-4a01-9836-5b74803f5ba5@github.com>

On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method.
>> 
>> The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce changes

The performance numbers are as follows

## MacBook M1 Pro

# baseline 
-Benchmark          (size)  Mode  Cnt  Score   Error  Units
-Longs.parseLong       500  avgt   15  2.613 ? 0.020  us/op
-Integers.parseInt     500  avgt   15  2.303 ? 0.006  us/op

+Benchmark          (size)  Mode  Cnt  Score   Error  Units
+Longs.parseLong       500  avgt   15  2.473 ? 0.020  us/op +5.66%
+Integers.parseInt     500  avgt   15  2.219 ? 0.002  us/op +3.78%


## MacBook 2018 i9

-Benchmark          (size)  Mode  Cnt  Score   Error  Units
-Integers.parseInt     500  avgt   15  3.114 ? 0.058  us/op
-Longs.parseLong       500  avgt   15  3.569 ? 0.059  us/op

+Benchmark          (size)  Mode  Cnt  Score   Error  Units
+Integers.parseInt     500  avgt   15  3.038 ? 0.033  us/op  +2.50%
+Longs.parseLong       500  avgt   15  3.065 ? 0.032  us/op +16.44%

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20168#issuecomment-2226731713

From liach at openjdk.org  Sat Jul 13 03:09:56 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 13 Jul 2024 03:09:56 GMT
Subject: <i18n dev> RFR: 8317980: Optimization for Integer.parseInt and
 Long.parseLong [v2]
In-Reply-To: <rGqTfS2h6uN1SJfgHLgLiaFOTu5DMGvEGErO06_Gvmk=.783ffe86-cee8-473b-8b9e-c47610d8f219@github.com>
References: <tc-wIpp8PRgt_KxxoJ8LMiLTYFXA3yTZ-ypI4aK4ttM=.dd9adc4a-b350-41c4-ab21-eeb74ac0ba35@github.com>
 <rGqTfS2h6uN1SJfgHLgLiaFOTu5DMGvEGErO06_Gvmk=.783ffe86-cee8-473b-8b9e-c47610d8f219@github.com>
Message-ID: <1iFWfuBYHJiCln8_ix1v__3mahl2hz115qXsoRmeL2A=.992206b7-833e-4898-86ac-58435c5c84b7@github.com>

On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method.
>> 
>> The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce changes

A straightforward guess would be converting the `Character.digit()` call to a utility method like:

private static int digit(char ch/*, int radix*/) {
    if (ch >= '0' && ch <= '9') // or replace it with something like Math.min('9', '0' + radix)
        return ch - '0'; // ascii base-10 fast path
    return digit(ch/*, radix*/);
}

Inspired by this: https://github.com/openjdk/jdk/blob/ae9f318fc35eeab497e546ebab9faed6ec774ec5/src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java#L236

However I don't know how JIT has compiled the code, so not sure how my speculative approach works compared to yours. But it is definitely somewhat less invasive, without the new table and latin1 requirements.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20168#issuecomment-2226736083

From duke at openjdk.org  Sat Jul 13 03:54:53 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 13 Jul 2024 03:54:53 GMT
Subject: <i18n dev> RFR: 8317980: Optimization for Integer.parseInt and
 Long.parseLong [v2]
In-Reply-To: <rGqTfS2h6uN1SJfgHLgLiaFOTu5DMGvEGErO06_Gvmk=.783ffe86-cee8-473b-8b9e-c47610d8f219@github.com>
References: <tc-wIpp8PRgt_KxxoJ8LMiLTYFXA3yTZ-ypI4aK4ttM=.dd9adc4a-b350-41c4-ab21-eeb74ac0ba35@github.com>
 <rGqTfS2h6uN1SJfgHLgLiaFOTu5DMGvEGErO06_Gvmk=.783ffe86-cee8-473b-8b9e-c47610d8f219@github.com>
Message-ID: <9Nmbr1TJ7N4HjG4T-j_oSR6rVKlVO9nC1LNepr6RVxk=.0ec79b18-cd9e-4f95-8e4a-6bd6829e73f1@github.com>

On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method.
>> 
>> The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce changes

> A straightforward guess would be converting the `Character.digit()` call to a utility method like:
> 
> ```java
> private static int digit(char ch/*, int radix*/) {
>     if (ch >= '0' && ch <= '9') // or replace it with something like Math.min('9', '0' + radix)
>         return ch - '0'; // ascii base-10 fast path
>     return digit(ch/*, radix*/);
> }
> ```
> 
> Inspired by this:
> 
> https://github.com/openjdk/jdk/blob/ae9f318fc35eeab497e546ebab9faed6ec774ec5/src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java#L236
> 
> However I don't know how JIT has compiled the code, so not sure how my speculative approach works compared to yours. But it is definitely somewhat less invasive, without the new table and latin1 requirements.

In the parse scenario, I made many attempts and found no method faster than table lookup, because the input length will be greater than 1 and the table will be looked up multiple times. In this scenario, I think it is correct to use table lookup.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20168#issuecomment-2226754795

From duke at openjdk.org  Mon Jul 15 02:14:29 2024
From: duke at openjdk.org (lingjun-cg)
Date: Mon, 15 Jul 2024 02:14:29 GMT
Subject: <i18n dev> RFR: 8333396: Use StringBuilder internally for
 java.text.Format.* formatting [v20]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <-EHsTdeytuK6CP4DyELyHHjgUIR3THZzp4gN67_IlrU=.deaa242d-6411-449e-ac92-cacc77ed1ef5@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with two additional commits since the last revision:

 - 8333396: Use StringBuilder internally for java.text.Format.* formatting
 - 8333396: Use StringBuilder internally for java.text.Format.* formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/6573e413..ee46eea3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=18-19

  Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From duke at openjdk.org  Mon Jul 15 02:30:54 2024
From: duke at openjdk.org (lingjun-cg)
Date: Mon, 15 Jul 2024 02:30:54 GMT
Subject: <i18n dev> RFR: 8333396: Use StringBuilder internally for
 java.text.Format.* formatting [v21]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <oxSW_g4NE10zOvZIvDXOgnZ5fzzwfJe_vIW2E2xz4IQ=.fcdc1915-3a09-4243-9fa2-879d9ba441c2@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Use StringBuilder internally for java.text.Format.* formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/ee46eea3..350085bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=19-20

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From mcimadamore at openjdk.org  Mon Jul 15 13:24:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Jul 2024 13:24:20 GMT
Subject: <i18n dev> RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v9]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <SNuYItiKx3q_g0ZUVt50iHQw67J-RmNEAP2c5M-kGeY=.bef589ad-fb18-40ff-b291-5da29d4d7451@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore 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 12 additional commits since the last revision:

 - Merge branch 'master' into restricted_jni
 - Address review comments
 - Add note on --illegal-native-access default value in the launcher help
 - Address review comment
 - Refine warning text for JNI method binding
 - Address review comments
   Improve warning for JNI methods, similar to what's described in JEP 472
   Beef up tests
 - Address review comments
 - Fix another typo
 - Fix typo
 - Add more comments
 - ... and 2 more: https://git.openjdk.org/jdk/compare/2ced23fe...ff51ac6a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/789bdf48..ff51ac6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=07-08

  Stats: 168976 lines in 3271 files changed: 114666 ins; 38249 del; 16061 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From mcimadamore at openjdk.org  Mon Jul 15 13:24:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Jul 2024 13:24:20 GMT
Subject: <i18n dev> RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <1f6cPvfYhyTzqeYoeA6uQi2WULB_Bq49AhF_RoEVWDQ=.9577a65e-b626-43fd-ab03-09783b978d94@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

keep alive

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2228489298

From jlu at openjdk.org  Mon Jul 15 19:35:58 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 15 Jul 2024 19:35:58 GMT
Subject: <i18n dev> [jdk23] Integrated: 8334653: ISO 4217 Amendment 177
 Update
In-Reply-To: <tnGlX8pfeN6haUdb3Gk89B4A84EK57vsXBdMezMkLyY=.4f7ad9fa-225b-49ad-9b30-417339b89e4f@github.com>
References: <tnGlX8pfeN6haUdb3Gk89B4A84EK57vsXBdMezMkLyY=.4f7ad9fa-225b-49ad-9b30-417339b89e4f@github.com>
Message-ID: <7nE7WdYxdFEr29sKhM5Non0AGc5hqhDhD51sDf8Ki-k=.11d012a1-115e-4d1b-9c9b-30d937b9c346@github.com>

On Wed, 10 Jul 2024 22:08:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) mainline branch.
> 
> This change incorporates the ISO 4217 Amendment 177 Update.

This pull request has now been integrated.

Changeset: 5162e1a3
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5162e1a31c1ec7e35211f3fa91416ac79c8c9a93
Stats:     23 lines in 6 files changed: 3 ins; 0 del; 20 mod

8334653: ISO 4217 Amendment 177 Update

Reviewed-by: naoto, iris
Backport-of: 86b0cf259fb3cbe3a1973151148e5d36c6a99d91

-------------

PR: https://git.openjdk.org/jdk/pull/20126

From naoto at openjdk.org  Tue Jul 16 16:38:20 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 Jul 2024 16:38:20 GMT
Subject: <i18n dev> RFR: 8336300: DateFormatSymbols#getInstanceRef returns
 non-cached instance
Message-ID: <aKQUk4HczgdSXDX5L0LZel9IEXygCH2VB2x6YhPzvpI=.0fe64ebd-1f28-41a4-b02e-5bf3b317f95d@github.com>

Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/20199/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20199&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336300
  Stats: 16 lines in 2 files changed: 0 ins; 14 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20199.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20199/head:pull/20199

PR: https://git.openjdk.org/jdk/pull/20199

From naoto at openjdk.org  Tue Jul 16 16:54:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 Jul 2024 16:54:09 GMT
Subject: <i18n dev> RFR: 8336300: DateFormatSymbols#getInstanceRef
 returns non-cached instance [v2]
In-Reply-To: <aKQUk4HczgdSXDX5L0LZel9IEXygCH2VB2x6YhPzvpI=.0fe64ebd-1f28-41a4-b02e-5bf3b317f95d@github.com>
References: <aKQUk4HczgdSXDX5L0LZel9IEXygCH2VB2x6YhPzvpI=.0fe64ebd-1f28-41a4-b02e-5bf3b317f95d@github.com>
Message-ID: <oYBA24ac2hlBfrt1HSc-knmJCl0-250Lj7Rm8WfkPwM=.74e3eb62-3ef7-4f17-aaa6-6d3c24917329@github.com>

> Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Removed unnecessary `this`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20199/files
  - new: https://git.openjdk.org/jdk/pull/20199/files/13dc1e74..4795076c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20199&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20199&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20199.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20199/head:pull/20199

PR: https://git.openjdk.org/jdk/pull/20199

From joehw at openjdk.org  Tue Jul 16 16:57:53 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 16 Jul 2024 16:57:53 GMT
Subject: <i18n dev> RFR: 8336300: DateFormatSymbols#getInstanceRef
 returns non-cached instance [v2]
In-Reply-To: <oYBA24ac2hlBfrt1HSc-knmJCl0-250Lj7Rm8WfkPwM=.74e3eb62-3ef7-4f17-aaa6-6d3c24917329@github.com>
References: <aKQUk4HczgdSXDX5L0LZel9IEXygCH2VB2x6YhPzvpI=.0fe64ebd-1f28-41a4-b02e-5bf3b317f95d@github.com>
 <oYBA24ac2hlBfrt1HSc-knmJCl0-250Lj7Rm8WfkPwM=.74e3eb62-3ef7-4f17-aaa6-6d3c24917329@github.com>
Message-ID: <4qtMD7cJup7BYwPCjz3gPK0STyj6a5wDiYEDb0uG7pA=.31f30467-5e01-4ff2-a043-17db3604b179@github.com>

On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary `this`

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20199#pullrequestreview-2180814858

From iris at openjdk.org  Tue Jul 16 17:06:51 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 16 Jul 2024 17:06:51 GMT
Subject: <i18n dev> RFR: 8336300: DateFormatSymbols#getInstanceRef
 returns non-cached instance [v2]
In-Reply-To: <oYBA24ac2hlBfrt1HSc-knmJCl0-250Lj7Rm8WfkPwM=.74e3eb62-3ef7-4f17-aaa6-6d3c24917329@github.com>
References: <aKQUk4HczgdSXDX5L0LZel9IEXygCH2VB2x6YhPzvpI=.0fe64ebd-1f28-41a4-b02e-5bf3b317f95d@github.com>
 <oYBA24ac2hlBfrt1HSc-knmJCl0-250Lj7Rm8WfkPwM=.74e3eb62-3ef7-4f17-aaa6-6d3c24917329@github.com>
Message-ID: <NDeHnFWxksWFAheioRvzvbGRQS9xdEUdohhki2-PZ90=.196a7a42-c20d-4057-8ea3-6fbd152b8e09@github.com>

On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary `this`

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20199#pullrequestreview-2180834740

From jlu at openjdk.org  Tue Jul 16 17:09:55 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 Jul 2024 17:09:55 GMT
Subject: <i18n dev> RFR: 8336300: DateFormatSymbols#getInstanceRef
 returns non-cached instance [v2]
In-Reply-To: <oYBA24ac2hlBfrt1HSc-knmJCl0-250Lj7Rm8WfkPwM=.74e3eb62-3ef7-4f17-aaa6-6d3c24917329@github.com>
References: <aKQUk4HczgdSXDX5L0LZel9IEXygCH2VB2x6YhPzvpI=.0fe64ebd-1f28-41a4-b02e-5bf3b317f95d@github.com>
 <oYBA24ac2hlBfrt1HSc-knmJCl0-250Lj7Rm8WfkPwM=.74e3eb62-3ef7-4f17-aaa6-6d3c24917329@github.com>
Message-ID: <wHsegBn4OT7T_wIiIBZrm_NkEEsEottzhV0wMCkgDc4=.9d062bf5-b947-454d-ba73-e914cc17ebb2@github.com>

On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary `this`

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20199#pullrequestreview-2180841390

From aturbanov at openjdk.org  Wed Jul 17 08:24:51 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 17 Jul 2024 08:24:51 GMT
Subject: <i18n dev> RFR: 8336300: DateFormatSymbols#getInstanceRef
 returns non-cached instance [v2]
In-Reply-To: <oYBA24ac2hlBfrt1HSc-knmJCl0-250Lj7Rm8WfkPwM=.74e3eb62-3ef7-4f17-aaa6-6d3c24917329@github.com>
References: <aKQUk4HczgdSXDX5L0LZel9IEXygCH2VB2x6YhPzvpI=.0fe64ebd-1f28-41a4-b02e-5bf3b317f95d@github.com>
 <oYBA24ac2hlBfrt1HSc-knmJCl0-250Lj7Rm8WfkPwM=.74e3eb62-3ef7-4f17-aaa6-6d3c24917329@github.com>
Message-ID: <2QoiYJeBYC8IIiCi6dGa6ETO0Tugx6IxjtmbHQQK4J4=.ae899c7d-1485-4e91-b1f9-b5e0342b5b01@github.com>

On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary `this`

Marked as reviewed by aturbanov (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20199#pullrequestreview-2182245319

From naoto at openjdk.org  Wed Jul 17 16:27:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 17 Jul 2024 16:27:55 GMT
Subject: <i18n dev> RFR: 8336300: DateFormatSymbols#getInstanceRef
 returns non-cached instance [v2]
In-Reply-To: <oYBA24ac2hlBfrt1HSc-knmJCl0-250Lj7Rm8WfkPwM=.74e3eb62-3ef7-4f17-aaa6-6d3c24917329@github.com>
References: <aKQUk4HczgdSXDX5L0LZel9IEXygCH2VB2x6YhPzvpI=.0fe64ebd-1f28-41a4-b02e-5bf3b317f95d@github.com>
 <oYBA24ac2hlBfrt1HSc-knmJCl0-250Lj7Rm8WfkPwM=.74e3eb62-3ef7-4f17-aaa6-6d3c24917329@github.com>
Message-ID: <fPP_y9zXABCqgUytHx1dOSLGAycPWkuLZMJjSwOEaig=.61b7908c-11de-4136-b663-c9f88ddce9aa@github.com>

On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary `this`

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20199#issuecomment-2233712534

From naoto at openjdk.org  Wed Jul 17 16:27:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 17 Jul 2024 16:27:56 GMT
Subject: <i18n dev> Integrated: 8336300: DateFormatSymbols#getInstanceRef
 returns non-cached instance
In-Reply-To: <aKQUk4HczgdSXDX5L0LZel9IEXygCH2VB2x6YhPzvpI=.0fe64ebd-1f28-41a4-b02e-5bf3b317f95d@github.com>
References: <aKQUk4HczgdSXDX5L0LZel9IEXygCH2VB2x6YhPzvpI=.0fe64ebd-1f28-41a4-b02e-5bf3b317f95d@github.com>
Message-ID: <QranfaZCTJq2gT8P1UpouyaAorhi9CsTze88u5cRLKc=.32bc607f-2da1-4d70-8340-222ee97cdd62@github.com>

On Tue, 16 Jul 2024 16:33:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description.

This pull request has now been integrated.

Changeset: 10186ff4
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10186ff48fe67aeb83c028b47f6b7e5105513cf3
Stats:     17 lines in 2 files changed: 0 ins; 14 del; 3 mod

8336300: DateFormatSymbols#getInstanceRef returns non-cached instance

Reviewed-by: joehw, iris, jlu, aturbanov

-------------

PR: https://git.openjdk.org/jdk/pull/20199

From duke at openjdk.org  Fri Jul 19 00:45:59 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 19 Jul 2024 00:45:59 GMT
Subject: <i18n dev> RFR: 8336792: DateTimeFormatterBuilder append zeros
 based on StringBuilder.repeat
Message-ID: <SaK8gIMSyGV75RPaYG_L3rq2YGMWTysL_YkoE4autmM=.61f8327b-d685-4426-ba34-0984380c4c0d@github.com>

The StringBuilder.repeat method was added in JDK 21, which can be used to make some minor optimizations to existing code, including DateTimeFormatterBuilder

-------------

Commit messages:
 - use StringBuilder#repeat append zeros

Changes: https://git.openjdk.org/jdk/pull/20245/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20245&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336792
  Stats: 12 lines in 1 file changed: 2 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20245.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20245/head:pull/20245

PR: https://git.openjdk.org/jdk/pull/20245

From duke at openjdk.org  Fri Jul 19 01:28:36 2024
From: duke at openjdk.org (lingjun-cg)
Date: Fri, 19 Jul 2024 01:28:36 GMT
Subject: <i18n dev> RFR: 8333396: Use StringBuilder internally for
 java.text.Format.* formatting [v17]
In-Reply-To: <Z1OetiJVJ1gFLlGmmff0JIpfGcldTWJZPj7Uy2ToLEg=.a9c14938-095c-43e0-8a62-c071023171e1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <HPksZxRtyhvMHKYbyAWum4kTrZzo45woJR5H59ZNdko=.ddecc6f8-0ae6-4193-956b-cc04b0672f53@github.com>
 <72jz9brO1nItDKitOCrcGYQMiEv4GKKfMUQvASiVH4c=.903656b2-bb11-40b3-b1a5-fe472d729a22@github.com>
 <Z1OetiJVJ1gFLlGmmff0JIpfGcldTWJZPj7Uy2ToLEg=.a9c14938-095c-43e0-8a62-c071023171e1@github.com>
Message-ID: <LF-iTAarQYF2AYpX2eqEFsEdgn4_p-r7nzqBVs4MkJ8=.4b8c9248-f81e-436a-badc-c04cd3eb8980@github.com>

On Mon, 8 Jul 2024 16:31:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Quick question about the violation of the "This is equivalent to" spec: Does our new implementation lead to any observable side effects that make the returned results or thrown exceptions different from that of `format(obj, new StringBuffer(), new FieldPosition(0)).toString()`?
>> 
>> In the ClassFile API, there are similar "behave as if" notes such as https://github.com/openjdk/jdk/blob/3f37c5718d676b7001e6a084aed3ba645745a144/src/java.base/share/classes/java/lang/classfile/ClassFile.java#L433-L438, yet we don't restrict implementations as the API surface, including the return an exception result and side effects are the same.
>
>> Quick question about the violation of the "This is equivalent to" spec: Does our new implementation lead to any observable side effects that make the returned results or thrown exceptions different from that of `format(obj, new StringBuffer(), new FieldPosition(0)).toString()`?
>> 
>> In the ClassFile API, there are similar "behave as if" notes such as
>> 
>> https://github.com/openjdk/jdk/blob/3f37c5718d676b7001e6a084aed3ba645745a144/src/java.base/share/classes/java/lang/classfile/ClassFile.java#L433-L438
>> 
>> , yet we don't restrict implementations as the API surface, including the return an exception result and side effects are the same.
> 
> AFAIK, there will be no behavioral difference, but I think CSR has to be accompanied with this issue to remove that wording, because it is not correct anymore.

@naotoj The CSR has been approved. Is it enough to start new review process?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2237844937

From liach at openjdk.org  Fri Jul 19 02:17:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 19 Jul 2024 02:17:33 GMT
Subject: <i18n dev> RFR: 8336792: DateTimeFormatterBuilder append zeros
 based on StringBuilder.repeat
In-Reply-To: <SaK8gIMSyGV75RPaYG_L3rq2YGMWTysL_YkoE4autmM=.61f8327b-d685-4426-ba34-0984380c4c0d@github.com>
References: <SaK8gIMSyGV75RPaYG_L3rq2YGMWTysL_YkoE4autmM=.61f8327b-d685-4426-ba34-0984380c4c0d@github.com>
Message-ID: <6nnYvAdJa9q_r1f0bjCD1I09EdL5ET371RzUSwSPi-8=.8bbd567a-6d68-4c4d-8c66-b5364fbd510d@github.com>

On Thu, 18 Jul 2024 23:36:37 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The StringBuilder.repeat method was added in JDK 21, which can be used to make some minor optimizations to existing code, including DateTimeFormatterBuilder

Looks good and simple.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20245#pullrequestreview-2187172092

From nbenalla at openjdk.org  Fri Jul 19 11:47:43 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 19 Jul 2024 11:47:43 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation
Message-ID: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>

Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).

It's mostly fixing some relative links.
If using `{@docroot}` isn't ideal I can change it.

Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 


diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
106c106
<  <p>
---
>  </p>
diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
99c99
<  <p>
---
> 
106c106
<  <p>
---
> 
618c618
<  <p>
---
> 
755c755
<  <p>
---
> 
783c783
< <p>
---
> 
diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
142c142
<  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
---
>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
120c120
<  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
---
>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
1420c1420
<           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
---
>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
1833c1833
<           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
---
>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
1899c1899
<           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
---
>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
395c395
<  <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>. The
---
>  <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>. The
diff -r docs-master/api/java.base/java/net/spi/InetAddressResolver.LookupPolicy.html docs/api/java.base/java/net/spi/InetAddressResolver.LookupPolicy.html
117c117
<  <a href="doc-files/net-properties.html#Ipv4IPv6">System Properties</a> which affect
---
>  <a href="../doc-files/net-properties.html#Ipv4IPv6">System Properties</a> which affect
diff -r docs-master/api/java.base/java/text/MessageFormat.html docs/api/java.base/java/text/MessageFormat.html
433,434c433
< 
<  <p>
---
>  </p>
diff -r docs-master/api/java.base/java/util/concurrent/StructuredTaskScope.ShutdownOnFailure.html docs/api/java.base/java/util/concurrent/StructuredTaskScope.ShutdownOnFailure.html
245c245
<  <a href="#TreeStructure">Tree Structure</a> section in the class description
---
>  <a href="../../../../java.base/java/util/concurrent/StructuredTaskScope.html#TreeStructure">Tree Structure</a> section in the class description
diff -r docs-master/api/java.base/java/util/concurrent/StructuredTaskScope.ShutdownOnSuccess.html docs/api/java.base/java/util/concurrent/StructuredTaskScope.ShutdownOnSuccess.html
242c242
<  <a href="#TreeStructure">Tree Structure</a> section in the class description
---
>  <a href="../../../../java.base/java/util/concurrent/StructuredTaskScope.html#TreeStructure">Tree Structure</a> section in the class description
diff -r docs-master/api/java.base/javax/security/auth/Subject.html docs/api/java.base/javax/security/auth/Subject.html
207,208c207,208
<  whether a security manager is
<  <a href="../../../java/lang/SecurityManager.html#set-security-manager">allowed or disallowed</a></a></b>:
---
>  whether a security manager is</a>
>  <a href="../../../java/lang/SecurityManager.html#set-security-manager">allowed or disallowed</a></b>:

-------------

Commit messages:
 - (C)
 - Merge remote-tracking branch 'upstream/master' into fix-broken-links-java-base
 - remove html warnings, broken links

Changes: https://git.openjdk.org/jdk/pull/20251/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20251&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336039
  Stats: 23 lines in 9 files changed: 0 ins; 1 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/20251.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20251/head:pull/20251

PR: https://git.openjdk.org/jdk/pull/20251

From djelinski at openjdk.org  Fri Jul 19 12:39:31 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Jul 2024 12:39:31 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation
In-Reply-To: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
Message-ID: <zrFOV9idWUTnDOJyjm2VGPXvsXKMJ9ODAzKWlShNpVw=.f5e57ed9-5429-496d-8867-476e0d9afd1c@github.com>

On Fri, 19 Jul 2024 11:11:38 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
> 
> It's mostly fixing some relative links.
> If using `{@docroot}` isn't ideal I can change it.
> 
> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
> 
> 
> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
> 106c106
> <  <p>
> ---
>>  </p>
> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
> 99c99
> <  <p>
> ---
>> 
> 106c106
> <  <p>
> ---
>> 
> 618c618
> <  <p>
> ---
>> 
> 755c755
> <  <p>
> ---
>> 
> 783c783
> < <p>
> ---
>> 
> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
> 142c142
> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
> ---
>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
> 120c120
> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
> ---
>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
> 1420c1420
> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
> ---
>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
> 1833c1833
> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
> ---
>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
> 1899c1899
> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
> ---
>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
> 395c395
> <  <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>. The
> ---
>>  <a href="../../../j...

src/java.base/share/classes/javax/security/auth/Subject.java line 111:

> 109:  * input type and exceptions thrown are slightly different.
> 110:  *
> 111:  * <p><b><a id="sm-allowed">These methods behave differently depending on

Suggestion:

 * <p id="sm-allowed"><b>These methods behave differently depending on

We seem to mix `<p id` and `<p><a id` in our code, so both forms should work fine, and the `<p id` form seems to be a better fit here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684315917

From djelinski at openjdk.org  Fri Jul 19 12:47:31 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Jul 2024 12:47:31 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation
In-Reply-To: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
Message-ID: <hV6bw7wl74P9-u1IbSUC_nhu9i4imKpUi6Jt62-f8aA=.9feb325c-200e-4f2b-8977-e6089a0bc30b@github.com>

On Fri, 19 Jul 2024 11:11:38 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
> 
> It's mostly fixing some relative links.
> If using `{@docroot}` isn't ideal I can change it.
> 
> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
> 
> 
> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
> 106c106
> <  <p>
> ---
>>  </p>
> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
> 99c99
> <  <p>
> ---
>> 
> 106c106
> <  <p>
> ---
>> 
> 618c618
> <  <p>
> ---
>> 
> 755c755
> <  <p>
> ---
>> 
> 783c783
> < <p>
> ---
>> 
> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
> 142c142
> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
> ---
>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
> 120c120
> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
> ---
>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
> 1420c1420
> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
> ---
>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
> 1833c1833
> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
> ---
>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
> 1899c1899
> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
> ---
>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
> 395c395
> <  <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>. The
> ---
>>  <a href="../../../j...

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1013:

> 1011:          * <p> Construction captures the current thread's {@linkplain ScopedValue scoped
> 1012:          * value} bindings for inheritance by threads started in the task scope. The
> 1013:          * <a href="{@docRoot}/java.base/java/util/concurrent/StructuredTaskScope.html#TreeStructure">Tree Structure</a> section in the class description

(untested, but should work)
Suggestion:

         * {@linkplain StructuredTaskScope##TreeStructure Tree Structure} section in the class description

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684324692

From nbenalla at openjdk.org  Fri Jul 19 13:08:06 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 19 Jul 2024 13:08:06 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v2]
In-Reply-To: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
Message-ID: <u51uAHNmQiulzLGuNjprglxSv7NHlc_aBPzPttXLYwA=.6f604fe5-a619-4471-bb69-af9649e3493c@github.com>

> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
> 
> It's mostly fixing some relative links.
> If using `{@docroot}` isn't ideal I can change it.
> 
> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
> 
> 
> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
> 106c106
> <  <p>
> ---
>>  </p>
> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
> 99c99
> <  <p>
> ---
>> 
> 106c106
> <  <p>
> ---
>> 
> 618c618
> <  <p>
> ---
>> 
> 755c755
> <  <p>
> ---
>> 
> 783c783
> < <p>
> ---
>> 
> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
> 142c142
> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
> ---
>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
> 120c120
> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
> ---
>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
> 1420c1420
> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
> ---
>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
> 1833c1833
> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
> ---
>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
> 1899c1899
> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
> ---
>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
> 395c395
> <  <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>. The
> ---
>>  <a href="../../../j...

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  remove docroot based on review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20251/files
  - new: https://git.openjdk.org/jdk/pull/20251/files/ddcdbc72..31649c74

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20251&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20251&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20251.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20251/head:pull/20251

PR: https://git.openjdk.org/jdk/pull/20251

From nbenalla at openjdk.org  Fri Jul 19 13:08:06 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 19 Jul 2024 13:08:06 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v2]
In-Reply-To: <hV6bw7wl74P9-u1IbSUC_nhu9i4imKpUi6Jt62-f8aA=.9feb325c-200e-4f2b-8977-e6089a0bc30b@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
 <hV6bw7wl74P9-u1IbSUC_nhu9i4imKpUi6Jt62-f8aA=.9feb325c-200e-4f2b-8977-e6089a0bc30b@github.com>
Message-ID: <kSqeXpL2fGj0B9PcFkaBwApJNvWBZ3xgjvuHfGs2JAc=.acc6deec-22d0-4c06-80a9-fe2444dc9653@github.com>

On Fri, 19 Jul 2024 12:44:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove docroot based on review
>
> src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1013:
> 
>> 1011:          * <p> Construction captures the current thread's {@linkplain ScopedValue scoped
>> 1012:          * value} bindings for inheritance by threads started in the task scope. The
>> 1013:          * <a href="{@docRoot}/java.base/java/util/concurrent/StructuredTaskScope.html#TreeStructure">Tree Structure</a> section in the class description
> 
> (untested, but should work)
> Suggestion:
> 
>          * {@linkplain StructuredTaskScope##TreeStructure Tree Structure} section in the class description

Fixed in [31649c7](https://github.com/openjdk/jdk/pull/20251/commits/31649c743e709cd67bd132774636e3484939890c), thanks.

> src/java.base/share/classes/javax/security/auth/Subject.java line 111:
> 
>> 109:  * input type and exceptions thrown are slightly different.
>> 110:  *
>> 111:  * <p><b><a id="sm-allowed">These methods behave differently depending on
> 
> Suggestion:
> 
>  * <p id="sm-allowed"><b>These methods behave differently depending on
> 
> We seem to mix `<p id` and `<p><a id` in our code, so both forms should work fine, and the `<p id` form seems to be a better fit here.

Fixed it, thanks. (I tried to not touch code beyond what was necessary for this PR)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684348983
PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684349446

From liach at openjdk.org  Fri Jul 19 13:10:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 19 Jul 2024 13:10:37 GMT
Subject: <i18n dev> RFR: 8333396: Use StringBuilder internally for
 java.text.Format.* formatting [v21]
In-Reply-To: <oxSW_g4NE10zOvZIvDXOgnZ5fzzwfJe_vIW2E2xz4IQ=.fcdc1915-3a09-4243-9fa2-879d9ba441c2@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <oxSW_g4NE10zOvZIvDXOgnZ5fzzwfJe_vIW2E2xz4IQ=.fcdc1915-3a09-4243-9fa2-879d9ba441c2@github.com>
Message-ID: <jk882mmlSyoy8gNZn10ghFra46vrnNRmtNUMjKYM7yQ=.b54e7612-ed0e-47a3-806a-74726123c393@github.com>

On Mon, 15 Jul 2024 02:30:54 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Use StringBuilder internally for java.text.Format.* formatting

Testing tier 1-3 passed.

src/java.base/share/classes/java/text/Format.java line 164:

> 162:      */
> 163:     public final String format (Object obj) {
> 164:         if ("java.text".equals(getClass().getPackageName())) {

We can use `==` for performance as getPackageName is interned.

src/java.base/share/classes/java/text/SimpleDateFormat.java line 1450:

> 1448:             //User can set numberFormat with a user-defined NumberFormat which
> 1449:             //not override format(long, StringBuf, FieldPosition).
> 1450:             if ("java.text".equals(numberFormat.getClass().getPackageName())) {

Same packagename remark

-------------

PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2188186196
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1684349563
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1684353454

From liach at openjdk.org  Fri Jul 19 13:14:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 19 Jul 2024 13:14:33 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v2]
In-Reply-To: <u51uAHNmQiulzLGuNjprglxSv7NHlc_aBPzPttXLYwA=.6f604fe5-a619-4471-bb69-af9649e3493c@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
 <u51uAHNmQiulzLGuNjprglxSv7NHlc_aBPzPttXLYwA=.6f604fe5-a619-4471-bb69-af9649e3493c@github.com>
Message-ID: <xj2cjNKwIE2sW8GobzGm4XdZInIgLtE4uWbMEENQYMM=.052bb802-1e57-4bc4-a022-6285604bfdf7@github.com>

On Fri, 19 Jul 2024 13:08:06 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
>> 
>> It's mostly fixing some relative links.
>> If using `{@docroot}` isn't ideal I can change it.
>> 
>> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
>> 
>> 
>> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
>> 106c106
>> <  <p>
>> ---
>>>  </p>
>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
>> 99c99
>> <  <p>
>> ---
>>> 
>> 106c106
>> <  <p>
>> ---
>>> 
>> 618c618
>> <  <p>
>> ---
>>> 
>> 755c755
>> <  <p>
>> ---
>>> 
>> 783c783
>> < <p>
>> ---
>>> 
>> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
>> 142c142
>> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
>> ---
>>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
>> 120c120
>> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
>> ---
>>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
>> 1420c1420
>> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
>> ---
>>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
>> 1833c1833
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> 1899c1899
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
>> 395c395
>> ...
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove docroot based on review

src/java.base/share/classes/java/lang/classfile/components/CodeStackTracker.java line 40:

> 38:  * <p>
> 39:  * Sample use:
> 40:  * <p>

This `<p>` intends to add a break. So I think you can just remove this new paragraph, like you've done below.

src/java.base/share/classes/java/lang/foreign/Arena.java line 64:

> 62:  * such, the regions of memory backing memory segments allocated with the automatic arena
> 63:  * are deallocated at some unspecified time <em>after</em> the automatic arena (and all
> 64:  * the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,

Suggestion:

 * the segments allocated by it) becomes {@linkplain java.lang.ref##reachability unreachable},

same for other occurrences.

src/java.base/share/classes/java/text/MessageFormat.java line 374:

> 372:  * In internationalized programs, the message format pattern and other
> 373:  * static strings will likely be obtained from resource bundles.
> 374:  * </p>

Same here, just remove `<p>` instead of adding a closing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684357333
PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684360034
PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684361244

From nbenalla at openjdk.org  Fri Jul 19 14:05:07 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 19 Jul 2024 14:05:07 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v3]
In-Reply-To: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
Message-ID: <aX6fJ4x5JLk_XbhFBuuEE4ArzlKOlK8ayFRC2WUk1GM=.845e38f1-dea1-4215-abfc-558c97065ec5@github.com>

> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
> 
> It's mostly fixing some relative links.
> If using `{@docroot}` isn't ideal I can change it.
> 
> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
> 
> 
> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
> 106c106
> <  <p>
> ---
>>  </p>
> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
> 99c99
> <  <p>
> ---
>> 
> 106c106
> <  <p>
> ---
>> 
> 618c618
> <  <p>
> ---
>> 
> 755c755
> <  <p>
> ---
>> 
> 783c783
> < <p>
> ---
>> 
> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
> 142c142
> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
> ---
>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
> 120c120
> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
> ---
>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
> 1420c1420
> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
> ---
>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
> 1833c1833
> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
> ---
>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
> 1899c1899
> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
> ---
>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
> 395c395
> <  <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>. The
> ---
>>  <a href="../../../j...

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  use @linkplain instead of href

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20251/files
  - new: https://git.openjdk.org/jdk/pull/20251/files/31649c74..c4e46f91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20251&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20251&range=01-02

  Stats: 9 lines in 6 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20251.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20251/head:pull/20251

PR: https://git.openjdk.org/jdk/pull/20251

From nbenalla at openjdk.org  Fri Jul 19 14:07:35 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 19 Jul 2024 14:07:35 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v2]
In-Reply-To: <u51uAHNmQiulzLGuNjprglxSv7NHlc_aBPzPttXLYwA=.6f604fe5-a619-4471-bb69-af9649e3493c@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
 <u51uAHNmQiulzLGuNjprglxSv7NHlc_aBPzPttXLYwA=.6f604fe5-a619-4471-bb69-af9649e3493c@github.com>
Message-ID: <FPQfNbuctdco7DUQgHqcwEnpmcTGR7t7xF6cqWL7J8A=.12e2e512-3d81-41b7-8399-03215be4e8b3@github.com>

On Fri, 19 Jul 2024 13:08:06 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
>> 
>> It's mostly fixing some relative links.
>> If using `{@docroot}` isn't ideal I can change it.
>> 
>> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
>> 
>> 
>> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
>> 106c106
>> <  <p>
>> ---
>>>  </p>
>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
>> 99c99
>> <  <p>
>> ---
>>> 
>> 106c106
>> <  <p>
>> ---
>>> 
>> 618c618
>> <  <p>
>> ---
>>> 
>> 755c755
>> <  <p>
>> ---
>>> 
>> 783c783
>> < <p>
>> ---
>>> 
>> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
>> 142c142
>> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
>> ---
>>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
>> 120c120
>> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
>> ---
>>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
>> 1420c1420
>> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
>> ---
>>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
>> 1833c1833
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> 1899c1899
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
>> 395c395
>> ...
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove docroot based on review

I replaced usages of `href` with `@linkplain` and removed unnecessary `<p>` tags

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20251#issuecomment-2239258426

From nbenalla at openjdk.org  Fri Jul 19 14:20:48 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 19 Jul 2024 14:20:48 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v4]
In-Reply-To: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
Message-ID: <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com>

> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
> 
> It's mostly fixing some relative links.
> If using `{@docroot}` isn't ideal I can change it.
> 
> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
> 
> 
> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
> 106c106
> <  <p>
> ---
>>  </p>
> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
> 99c99
> <  <p>
> ---
>> 
> 106c106
> <  <p>
> ---
>> 
> 618c618
> <  <p>
> ---
>> 
> 755c755
> <  <p>
> ---
>> 
> 783c783
> < <p>
> ---
>> 
> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
> 142c142
> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
> ---
>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
> 120c120
> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
> ---
>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
> 1420c1420
> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
> ---
>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
> 1833c1833
> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
> ---
>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
> 1899c1899
> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
> ---
>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
> 395c395
> <  <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>. The
> ---
>>  <a href="../../../j...

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
  
  forgot this one
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20251/files
  - new: https://git.openjdk.org/jdk/pull/20251/files/c4e46f91..d8aeca9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20251&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20251&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20251.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20251/head:pull/20251

PR: https://git.openjdk.org/jdk/pull/20251

From liach at openjdk.org  Fri Jul 19 14:20:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 19 Jul 2024 14:20:49 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v3]
In-Reply-To: <aX6fJ4x5JLk_XbhFBuuEE4ArzlKOlK8ayFRC2WUk1GM=.845e38f1-dea1-4215-abfc-558c97065ec5@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
 <aX6fJ4x5JLk_XbhFBuuEE4ArzlKOlK8ayFRC2WUk1GM=.845e38f1-dea1-4215-abfc-558c97065ec5@github.com>
Message-ID: <qyVO2DSrPlWTOQJTMD4EWUVUfI2mPvNIAickYCxlStA=.a1e4db71-ec15-4775-b05e-d24c1c8b764b@github.com>

On Fri, 19 Jul 2024 14:05:07 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
>> 
>> It's mostly fixing some relative links.
>> If using `{@docroot}` isn't ideal I can change it.
>> 
>> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
>> 
>> 
>> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
>> 106c106
>> <  <p>
>> ---
>>>  </p>
>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
>> 99c99
>> <  <p>
>> ---
>>> 
>> 106c106
>> <  <p>
>> ---
>>> 
>> 618c618
>> <  <p>
>> ---
>>> 
>> 755c755
>> <  <p>
>> ---
>>> 
>> 783c783
>> < <p>
>> ---
>>> 
>> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
>> 142c142
>> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
>> ---
>>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
>> 120c120
>> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
>> ---
>>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
>> 1420c1420
>> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
>> ---
>>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
>> 1833c1833
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> 1899c1899
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
>> 395c395
>> ...
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use @linkplain instead of href

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2665:

> 2663:      * garbage collector. A segment scope that is invalidated automatically is an
> 2664:      * <em>automatic scope</em>. An automatic scope is always {@link #isAlive() alive}
> 2665:      * as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.

Suggestion:

     * as long as it is {@linkplain java.lang.ref##reachability reachable}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684450266

From rriggs at openjdk.org  Fri Jul 19 14:32:39 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 Jul 2024 14:32:39 GMT
Subject: <i18n dev> RFR: 8333396: Use StringBuilder internally for
 java.text.Format.* formatting [v21]
In-Reply-To: <jk882mmlSyoy8gNZn10ghFra46vrnNRmtNUMjKYM7yQ=.b54e7612-ed0e-47a3-806a-74726123c393@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <oxSW_g4NE10zOvZIvDXOgnZ5fzzwfJe_vIW2E2xz4IQ=.fcdc1915-3a09-4243-9fa2-879d9ba441c2@github.com>
 <jk882mmlSyoy8gNZn10ghFra46vrnNRmtNUMjKYM7yQ=.b54e7612-ed0e-47a3-806a-74726123c393@github.com>
Message-ID: <EGf-6uj2RNCMMnsa5juxM1_9HE4qZPmbc75BcdWa8LA=.eed9aa7d-0dba-4065-af57-2c722d603671@github.com>

On Fri, 19 Jul 2024 13:03:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Use StringBuilder internally for java.text.Format.* formatting
>
> src/java.base/share/classes/java/text/Format.java line 164:
> 
>> 162:      */
>> 163:     public final String format (Object obj) {
>> 164:         if ("java.text".equals(getClass().getPackageName())) {
> 
> We can use `==` for performance as getPackageName is interned.

Using equals() is fine and the performance is the same.
Using "==" may be fewer characters but carries with it the need to understand that the arguments are interned and that's not always obvious or known.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1684469032

From rriggs at openjdk.org  Fri Jul 19 15:19:34 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 Jul 2024 15:19:34 GMT
Subject: <i18n dev> RFR: 8336792: DateTimeFormatterBuilder append zeros
 based on StringBuilder.repeat
In-Reply-To: <SaK8gIMSyGV75RPaYG_L3rq2YGMWTysL_YkoE4autmM=.61f8327b-d685-4426-ba34-0984380c4c0d@github.com>
References: <SaK8gIMSyGV75RPaYG_L3rq2YGMWTysL_YkoE4autmM=.61f8327b-d685-4426-ba34-0984380c4c0d@github.com>
Message-ID: <l-Y3SPBcf7rs8vulVHmDic2WIW87hkBeLRSn50QrT8c=.3b97f5b3-c8de-4df5-9265-d172494d5990@github.com>

On Thu, 18 Jul 2024 23:36:37 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The StringBuilder.repeat method was added in JDK 21, which can be used to make some minor optimizations to existing code, including DateTimeFormatterBuilder

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20245#pullrequestreview-2188493177

From liach at openjdk.org  Fri Jul 19 15:44:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 19 Jul 2024 15:44:34 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v4]
In-Reply-To: <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
 <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com>
Message-ID: <YMm8mwFRXUFi1BXNJD2nQL1HTrmSZJFs_XcyEUWZaUw=.b6e489f6-920e-410e-a4f9-4325196a2c9c@github.com>

On Fri, 19 Jul 2024 14:20:48 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
>> 
>> It's mostly fixing some relative links.
>> If using `{@docroot}` isn't ideal I can change it.
>> 
>> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
>> 
>> 
>> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
>> 106c106
>> <  <p>
>> ---
>>>  </p>
>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
>> 99c99
>> <  <p>
>> ---
>>> 
>> 106c106
>> <  <p>
>> ---
>>> 
>> 618c618
>> <  <p>
>> ---
>>> 
>> 755c755
>> <  <p>
>> ---
>>> 
>> 783c783
>> < <p>
>> ---
>>> 
>> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
>> 142c142
>> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
>> ---
>>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
>> 120c120
>> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
>> ---
>>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
>> 1420c1420
>> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
>> ---
>>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
>> 1833c1833
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> 1899c1899
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
>> 395c395
>> ...
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>   
>   forgot this one
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Lgtm

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20251#pullrequestreview-2188544805

From djelinski at openjdk.org  Fri Jul 19 15:53:34 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Jul 2024 15:53:34 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v4]
In-Reply-To: <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
 <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com>
Message-ID: <oN45MOm-BTDlWn0lWakgv9CAth6JgF1_gdOdW2ZMSmo=.f7b7caf5-5b01-44e6-89e0-77ee55f17f3f@github.com>

On Fri, 19 Jul 2024 14:20:48 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
>> 
>> It's mostly fixing some relative links.
>> If using `{@docroot}` isn't ideal I can change it.
>> 
>> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
>> 
>> 
>> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
>> 106c106
>> <  <p>
>> ---
>>>  </p>
>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
>> 99c99
>> <  <p>
>> ---
>>> 
>> 106c106
>> <  <p>
>> ---
>>> 
>> 618c618
>> <  <p>
>> ---
>>> 
>> 755c755
>> <  <p>
>> ---
>>> 
>> 783c783
>> < <p>
>> ---
>>> 
>> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
>> 142c142
>> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
>> ---
>>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
>> 120c120
>> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
>> ---
>>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
>> 1420c1420
>> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
>> ---
>>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
>> 1833c1833
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> 1899c1899
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
>> 395c395
>> ...
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>   
>   forgot this one
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20251#pullrequestreview-2188559747

From djelinski at openjdk.org  Fri Jul 19 15:53:36 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Jul 2024 15:53:36 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v2]
In-Reply-To: <xj2cjNKwIE2sW8GobzGm4XdZInIgLtE4uWbMEENQYMM=.052bb802-1e57-4bc4-a022-6285604bfdf7@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
 <u51uAHNmQiulzLGuNjprglxSv7NHlc_aBPzPttXLYwA=.6f604fe5-a619-4471-bb69-af9649e3493c@github.com>
 <xj2cjNKwIE2sW8GobzGm4XdZInIgLtE4uWbMEENQYMM=.052bb802-1e57-4bc4-a022-6285604bfdf7@github.com>
Message-ID: <Ovm_KFkwEtoX6Yd8ti9g7-fFjHGbKytAU9Wf1smEFHU=.1f2013da-c119-4a93-9d80-bb79455d5224@github.com>

On Fri, 19 Jul 2024 13:11:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove docroot based on review
>
> src/java.base/share/classes/java/lang/foreign/Arena.java line 64:
> 
>> 62:  * such, the regions of memory backing memory segments allocated with the automatic arena
>> 63:  * are deallocated at some unspecified time <em>after</em> the automatic arena (and all
>> 64:  * the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
> 
> Suggestion:
> 
>  * the segments allocated by it) becomes {@linkplain java.lang.ref##reachability unreachable},
> 
> same for other occurrences.

TIL

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684571249

From naoto at openjdk.org  Fri Jul 19 17:12:32 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Jul 2024 17:12:32 GMT
Subject: <i18n dev> RFR: 8336792: DateTimeFormatterBuilder append zeros
 based on StringBuilder.repeat
In-Reply-To: <SaK8gIMSyGV75RPaYG_L3rq2YGMWTysL_YkoE4autmM=.61f8327b-d685-4426-ba34-0984380c4c0d@github.com>
References: <SaK8gIMSyGV75RPaYG_L3rq2YGMWTysL_YkoE4autmM=.61f8327b-d685-4426-ba34-0984380c4c0d@github.com>
Message-ID: <03vQdyS2YilbQPW7gaLOvrYirfr6fJiq2oDNGt-82lA=.609db38a-4118-4632-adcb-53752ae019c9@github.com>

On Thu, 18 Jul 2024 23:36:37 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The StringBuilder.repeat method was added in JDK 21, which can be used to make some minor optimizations to existing code, including DateTimeFormatterBuilder

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20245#pullrequestreview-2188736912

From liach at openjdk.org  Fri Jul 19 17:17:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 19 Jul 2024 17:17:31 GMT
Subject: <i18n dev> RFR: 8336792: DateTimeFormatterBuilder append zeros
 based on StringBuilder.repeat
In-Reply-To: <SaK8gIMSyGV75RPaYG_L3rq2YGMWTysL_YkoE4autmM=.61f8327b-d685-4426-ba34-0984380c4c0d@github.com>
References: <SaK8gIMSyGV75RPaYG_L3rq2YGMWTysL_YkoE4autmM=.61f8327b-d685-4426-ba34-0984380c4c0d@github.com>
Message-ID: <3_mApjCLauB3HwDzTBDa3eeqGjpLNzWNz3xl8Bcu7B8=.ac0b5bf2-cce3-4276-9201-8426b3bb08f2@github.com>

On Thu, 18 Jul 2024 23:36:37 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The StringBuilder.repeat method was added in JDK 21, which can be used to make some minor optimizations to existing code, including DateTimeFormatterBuilder

Tier 1-3 tests come back all passing as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20245#issuecomment-2239708288

From naoto at openjdk.org  Fri Jul 19 20:49:38 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Jul 2024 20:49:38 GMT
Subject: <i18n dev> RFR: 8333396: Use StringBuilder internally for
 java.text.Format.* formatting [v21]
In-Reply-To: <oxSW_g4NE10zOvZIvDXOgnZ5fzzwfJe_vIW2E2xz4IQ=.fcdc1915-3a09-4243-9fa2-879d9ba441c2@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <oxSW_g4NE10zOvZIvDXOgnZ5fzzwfJe_vIW2E2xz4IQ=.fcdc1915-3a09-4243-9fa2-879d9ba441c2@github.com>
Message-ID: <j5iTBrBrqcZI-sttZqLngHA1mwtmZxoNvrQ61RMe15M=.2ed1b04d-c828-440b-a83f-2a06a08a0aea@github.com>

On Mon, 15 Jul 2024 02:30:54 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Use StringBuilder internally for java.text.Format.* formatting

LGTM. Thanks for the changes.

src/java.base/share/classes/java/text/CompactNumberFormat.java line 583:

> 581:                                 && ((BigInteger) number).bitLength() < 64)) {
> 582:             return format(((Number) number).longValue(), toAppendTo,
> 583:                     fieldPosition);

This is a prime example for switch pattern match, but probably for another day.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2189197549
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1684957942

From liach at openjdk.org  Fri Jul 19 20:56:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 19 Jul 2024 20:56:37 GMT
Subject: <i18n dev> RFR: 8333396: Use StringBuilder internally for
 java.text.Format.* formatting [v21]
In-Reply-To: <oxSW_g4NE10zOvZIvDXOgnZ5fzzwfJe_vIW2E2xz4IQ=.fcdc1915-3a09-4243-9fa2-879d9ba441c2@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <oxSW_g4NE10zOvZIvDXOgnZ5fzzwfJe_vIW2E2xz4IQ=.fcdc1915-3a09-4243-9fa2-879d9ba441c2@github.com>
Message-ID: <onuZB2CyDP-djhRX91HEu9H95xOC411ACZSqqS7aTKc=.2abe47c5-4592-42ed-851c-c0dedffd397e@github.com>

On Mon, 15 Jul 2024 02:30:54 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Use StringBuilder internally for java.text.Format.* formatting

Looks good indeed! Thanks for your hard work.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2189218782

From naoto at openjdk.org  Fri Jul 19 21:21:44 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Jul 2024 21:21:44 GMT
Subject: <i18n dev> RFR: 8333396: Use StringBuilder internally for
 java.text.Format.* formatting [v21]
In-Reply-To: <j5iTBrBrqcZI-sttZqLngHA1mwtmZxoNvrQ61RMe15M=.2ed1b04d-c828-440b-a83f-2a06a08a0aea@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <oxSW_g4NE10zOvZIvDXOgnZ5fzzwfJe_vIW2E2xz4IQ=.fcdc1915-3a09-4243-9fa2-879d9ba441c2@github.com>
 <j5iTBrBrqcZI-sttZqLngHA1mwtmZxoNvrQ61RMe15M=.2ed1b04d-c828-440b-a83f-2a06a08a0aea@github.com>
Message-ID: <0515kIRPIKqztCAVemcPP3IktMRIKy2iax-a-MLAq-4=.f0424cba-5e86-485c-8939-f97879f19f33@github.com>

On Fri, 19 Jul 2024 20:46:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Use StringBuilder internally for java.text.Format.* formatting
>
> src/java.base/share/classes/java/text/CompactNumberFormat.java line 583:
> 
>> 581:                                 && ((BigInteger) number).bitLength() < 64)) {
>> 582:             return format(((Number) number).longValue(), toAppendTo,
>> 583:                     fieldPosition);
> 
> This is a prime example for switch pattern match, but probably for another day.

Filed: https://bugs.openjdk.org/browse/JDK-8336847

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1684986049

From duke at openjdk.org  Fri Jul 19 21:52:33 2024
From: duke at openjdk.org (duke)
Date: Fri, 19 Jul 2024 21:52:33 GMT
Subject: <i18n dev> RFR: 8336792: DateTimeFormatterBuilder append zeros
 based on StringBuilder.repeat
In-Reply-To: <SaK8gIMSyGV75RPaYG_L3rq2YGMWTysL_YkoE4autmM=.61f8327b-d685-4426-ba34-0984380c4c0d@github.com>
References: <SaK8gIMSyGV75RPaYG_L3rq2YGMWTysL_YkoE4autmM=.61f8327b-d685-4426-ba34-0984380c4c0d@github.com>
Message-ID: <nBRK1xGOJkhHJqAJvsDqJtr94KITuTuPLsOrEu1kuNA=.3ba6d78b-9c28-4732-aa37-b89456f6b6c9@github.com>

On Thu, 18 Jul 2024 23:36:37 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The StringBuilder.repeat method was added in JDK 21, which can be used to make some minor optimizations to existing code, including DateTimeFormatterBuilder

@wenshao 
Your change (at version db3027b03030304dbec990c943eff0f037363e37) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20245#issuecomment-2240263706

From duke at openjdk.org  Fri Jul 19 22:09:48 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 19 Jul 2024 22:09:48 GMT
Subject: <i18n dev> Integrated: 8336792: DateTimeFormatterBuilder append
 zeros based on StringBuilder.repeat
In-Reply-To: <SaK8gIMSyGV75RPaYG_L3rq2YGMWTysL_YkoE4autmM=.61f8327b-d685-4426-ba34-0984380c4c0d@github.com>
References: <SaK8gIMSyGV75RPaYG_L3rq2YGMWTysL_YkoE4autmM=.61f8327b-d685-4426-ba34-0984380c4c0d@github.com>
Message-ID: <FJqrM7SQITmDBDq37rh6pUGustIfK6sQlf3_UaaTBOM=.ce37ed04-2df6-446a-ac29-9eff4952c0b6@github.com>

On Thu, 18 Jul 2024 23:36:37 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The StringBuilder.repeat method was added in JDK 21, which can be used to make some minor optimizations to existing code, including DateTimeFormatterBuilder

This pull request has now been integrated.

Changeset: e3acf4c6
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3acf4c627c3c75f9a2ef29647daa6f4746fdc62
Stats:     12 lines in 1 file changed: 2 ins; 4 del; 6 mod

8336792: DateTimeFormatterBuilder append zeros based on StringBuilder.repeat

Reviewed-by: liach, rriggs, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/20245

From duke at openjdk.org  Fri Jul 19 23:09:31 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 19 Jul 2024 23:09:31 GMT
Subject: <i18n dev> =?utf-8?b?UkZSOiA4MzM1NzkxOiBTcGVlZCDigIvigIt1cCBq?=
 =?utf-8?b?LnUuRm9ybWF0dGVyICYgU3RyaW5nLmZvcm1hdCBbdjRd?=
In-Reply-To: <hGJeZFind-4U7DFNVShiFE0xDqSvikSH_SXt9aBRhXc=.05cc29eb-d01b-4481-aeac-28f68b89579c@github.com>
References: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
 <hGJeZFind-4U7DFNVShiFE0xDqSvikSH_SXt9aBRhXc=.05cc29eb-d01b-4481-aeac-28f68b89579c@github.com>
Message-ID: <bFF2nfoaL9QSoDOhb2MhTPK8RXrXfm0lfe3J4EeRg8Q=.12fe209d-1517-4480-afad-6204630973a1@github.com>

On Sat, 6 Jul 2024 00:15:04 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently.
>> 
>> 
>> Improved performance includes the following:
>> 
>> ## 1. Write directly during the parse process to reduce object allocation.
>> 
>> In the current Formatter implementation, some objects do not need to be allocated, such as:
>> 
>> 
>> class Formatter {
>>     public Formatter format(Locale l, String format, Object ... args) {
>>     	List<FormatString> fsa = parse(format);
>>     	// ...
>>     }
>> 
>>     static List<FormatString> parse(String s) {
>>     	ArrayList<FormatString> al = new ArrayList<>();
>> 
>>         while (i < max) {
>>             int n = s.indexOf('%', i);
>>             if (n < 0) {
>>                 // 
>>                 al.add(new FixedString(s, i, max));
>>             }
>>         }
>>     }
>> }
>> 
>> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List<FormatString> fsa` to store it.
>> 
>> ## 2. Fast path print
>> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method.
>> 
>> ## 3. String.format directly calls j.u.Formatter
>> String.format directly calls j.u.Formatter via SharedSecrets to improve performance
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implementing JavaUtilFormatterAccess using anonymous class

This PR has a lot of changes, which is a lot of work for review, but it can significantly improve the performance of most String.format scenarios. String.format is widely used, so it is meaningful.

Can someone help me review and finish it? Thanks

@cl4es @liach

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20055#issuecomment-2240562362

From alanb at openjdk.org  Sat Jul 20 15:12:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 20 Jul 2024 15:12:32 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v4]
In-Reply-To: <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
 <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com>
Message-ID: <QQqAXmc8OdGGoWv_V8pFg_71eN1K5hchwFDawgEve7I=.9e73fcca-1b18-4e3c-98f5-f893471caad7@github.com>

On Fri, 19 Jul 2024 14:20:48 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
>> 
>> It's mostly fixing some relative links.
>> If using `{@docroot}` isn't ideal I can change it.
>> 
>> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
>> 
>> 
>> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
>> 106c106
>> <  <p>
>> ---
>>>  </p>
>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
>> 99c99
>> <  <p>
>> ---
>>> 
>> 106c106
>> <  <p>
>> ---
>>> 
>> 618c618
>> <  <p>
>> ---
>>> 
>> 755c755
>> <  <p>
>> ---
>>> 
>> 783c783
>> < <p>
>> ---
>>> 
>> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
>> 142c142
>> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
>> ---
>>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
>> 120c120
>> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
>> ---
>>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
>> 1420c1420
>> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
>> ---
>>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
>> 1833c1833
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> 1899c1899
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
>> 395c395
>> ...
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>   
>   forgot this one
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1200:

> 1198:          * <p> Construction captures the current thread's {@linkplain ScopedValue scoped
> 1199:          * value} bindings for inheritance by threads started in the task scope. The
> 1200:          * {@linkplain StructuredTaskScope##TreeStructure Tree Structure} section in the class description

You can drop the changes to STS if you want as we have an update coming that replaces these paragraphs/links.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1685465093

From nbenalla at openjdk.org  Sun Jul 21 21:15:03 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sun, 21 Jul 2024 21:15:03 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v5]
In-Reply-To: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
Message-ID: <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com>

> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
> 
> It's mostly fixing some relative links.
> If using `{@docroot}` isn't ideal I can change it.
> 
> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
> 
> 
> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
> 106c106
> <  <p>
> ---
>>  </p>
> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
> 99c99
> <  <p>
> ---
>> 
> 106c106
> <  <p>
> ---
>> 
> 618c618
> <  <p>
> ---
>> 
> 755c755
> <  <p>
> ---
>> 
> 783c783
> < <p>
> ---
>> 
> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
> 142c142
> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
> ---
>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
> 120c120
> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
> ---
>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
> 1420c1420
> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
> ---
>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
> 1833c1833
> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
> ---
>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
> 1899c1899
> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
> ---
>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
> 395c395
> <  <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>. The
> ---
>>  <a href="../../../j...

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  undo changes to StructuredTaskScope

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20251/files
  - new: https://git.openjdk.org/jdk/pull/20251/files/d8aeca9e..4d5d8784

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20251&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20251&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20251.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20251/head:pull/20251

PR: https://git.openjdk.org/jdk/pull/20251

From nbenalla at openjdk.org  Sun Jul 21 21:15:04 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sun, 21 Jul 2024 21:15:04 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v4]
In-Reply-To: <QQqAXmc8OdGGoWv_V8pFg_71eN1K5hchwFDawgEve7I=.9e73fcca-1b18-4e3c-98f5-f893471caad7@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
 <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com>
 <QQqAXmc8OdGGoWv_V8pFg_71eN1K5hchwFDawgEve7I=.9e73fcca-1b18-4e3c-98f5-f893471caad7@github.com>
Message-ID: <J7_p-js_kAFDQEuT2Q5hm7a8E_OvHB-NEgfFjSHkqoE=.9a3b0de5-1f96-49d7-9ecd-e938d4d18cde@github.com>

On Sat, 20 Jul 2024 15:10:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>>   
>>   forgot this one
>>   
>>   Co-authored-by: Chen Liang <liach at openjdk.org>
>
> src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1200:
> 
>> 1198:          * <p> Construction captures the current thread's {@linkplain ScopedValue scoped
>> 1199:          * value} bindings for inheritance by threads started in the task scope. The
>> 1200:          * {@linkplain StructuredTaskScope##TreeStructure Tree Structure} section in the class description
> 
> You can drop the changes to STS if you want as we have an update coming that replaces these paragraphs/links.

Done, thanks for the heads up!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1685812825

From liach at openjdk.org  Sun Jul 21 23:37:32 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 21 Jul 2024 23:37:32 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v5]
In-Reply-To: <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
 <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com>
Message-ID: <tuCgGN1d4zmflhPZaOcqMdtGboH9KxZ33qwgsFmymaw=.890f8cd7-ba77-4124-a7c2-afbbee27ade0@github.com>

On Sun, 21 Jul 2024 21:15:03 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
>> 
>> It's mostly fixing some relative links.
>> If using `{@docroot}` isn't ideal I can change it.
>> 
>> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
>> 
>> 
>> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
>> 106c106
>> <  <p>
>> ---
>>>  </p>
>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
>> 99c99
>> <  <p>
>> ---
>>> 
>> 106c106
>> <  <p>
>> ---
>>> 
>> 618c618
>> <  <p>
>> ---
>>> 
>> 755c755
>> <  <p>
>> ---
>>> 
>> 783c783
>> < <p>
>> ---
>>> 
>> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
>> 142c142
>> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
>> ---
>>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
>> 120c120
>> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
>> ---
>>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
>> 1420c1420
>> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
>> ---
>>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
>> 1833c1833
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> 1899c1899
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
>> 395c395
>> ...
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo changes to StructuredTaskScope

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20251#pullrequestreview-2190420126

From duke at openjdk.org  Mon Jul 22 02:00:39 2024
From: duke at openjdk.org (duke)
Date: Mon, 22 Jul 2024 02:00:39 GMT
Subject: <i18n dev> RFR: 8333396: Use StringBuilder internally for
 java.text.Format.* formatting [v21]
In-Reply-To: <oxSW_g4NE10zOvZIvDXOgnZ5fzzwfJe_vIW2E2xz4IQ=.fcdc1915-3a09-4243-9fa2-879d9ba441c2@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <oxSW_g4NE10zOvZIvDXOgnZ5fzzwfJe_vIW2E2xz4IQ=.fcdc1915-3a09-4243-9fa2-879d9ba441c2@github.com>
Message-ID: <9L0V9K3Mhv0yvJwvteR8jJPWkHH8bfg6uf1NuQ-3CGE=.4ecc2b4f-94e1-46c1-8b59-3173e7b4f40b@github.com>

On Mon, 15 Jul 2024 02:30:54 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Use StringBuilder internally for java.text.Format.* formatting

@lingjun-cg 
Your change (at version 350085bd835798147bbf2b494e49615536dcc8c4) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2241903106

From duke at openjdk.org  Mon Jul 22 02:04:07 2024
From: duke at openjdk.org (lingjun-cg)
Date: Mon, 22 Jul 2024 02:04:07 GMT
Subject: <i18n dev> Integrated: 8333396: Use StringBuilder internally for
 java.text.Format.* formatting
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <uvebBLNnil2WPhJzifUk-ojAAvLUnXRNjx-lHf62S3Q=.cca1e3ae-e26b-446f-bd1b-2aa601ebb122@github.com>

On Mon, 3 Jun 2024 04:18:20 GMT, lingjun-cg <duke at openjdk.org> wrote:

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

This pull request has now been integrated.

Changeset: 4da99158
Author:    lingjun.cg <lingjun.cg at alibaba-inc.com>
URL:       https://git.openjdk.org/jdk/commit/4da99158754c25c5d0650f2d042aad3e94a9b0c5
Stats:     765 lines in 16 files changed: 692 ins; 1 del; 72 mod

8333396: Use StringBuilder internally for java.text.Format.* formatting

Reviewed-by: naoto, liach, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/19513

From djelinski at openjdk.org  Mon Jul 22 11:32:34 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 22 Jul 2024 11:32:34 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v5]
In-Reply-To: <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
 <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com>
Message-ID: <nUWrK69XT7bWr22PyXohfdT2O-WERcl6cF4LDa5bwow=.349d0ee5-42f5-4156-ae8d-9aa26bacbbe4@github.com>

On Sun, 21 Jul 2024 21:15:03 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
>> 
>> It's mostly fixing some relative links.
>> If using `{@docroot}` isn't ideal I can change it.
>> 
>> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
>> 
>> 
>> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
>> 106c106
>> <  <p>
>> ---
>>>  </p>
>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
>> 99c99
>> <  <p>
>> ---
>>> 
>> 106c106
>> <  <p>
>> ---
>>> 
>> 618c618
>> <  <p>
>> ---
>>> 
>> 755c755
>> <  <p>
>> ---
>>> 
>> 783c783
>> < <p>
>> ---
>>> 
>> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
>> 142c142
>> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
>> ---
>>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
>> 120c120
>> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
>> ---
>>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
>> 1420c1420
>> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
>> ---
>>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
>> 1833c1833
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> 1899c1899
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
>> 395c395
>> ...
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo changes to StructuredTaskScope

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20251#pullrequestreview-2191324725

From nbenalla at openjdk.org  Mon Jul 22 13:05:36 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 22 Jul 2024 13:05:36 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v5]
In-Reply-To: <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
 <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com>
Message-ID: <Cx9JP6pq3peTiQYrMEBCGqS2jWEg0IzvWg_VYJ6FqdA=.db16d82c-0478-48ac-9d40-049564381adb@github.com>

On Sun, 21 Jul 2024 21:15:03 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
>> 
>> It's mostly fixing some relative links.
>> If using `{@docroot}` isn't ideal I can change it.
>> 
>> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
>> 
>> 
>> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
>> 106c106
>> <  <p>
>> ---
>>>  </p>
>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
>> 99c99
>> <  <p>
>> ---
>>> 
>> 106c106
>> <  <p>
>> ---
>>> 
>> 618c618
>> <  <p>
>> ---
>>> 
>> 755c755
>> <  <p>
>> ---
>>> 
>> 783c783
>> < <p>
>> ---
>>> 
>> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
>> 142c142
>> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
>> ---
>>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
>> 120c120
>> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
>> ---
>>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
>> 1420c1420
>> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
>> ---
>>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
>> 1833c1833
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> 1899c1899
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
>> 395c395
>> ...
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo changes to StructuredTaskScope

thank you for the reviews, again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20251#issuecomment-2242906326

From duke at openjdk.org  Mon Jul 22 13:05:36 2024
From: duke at openjdk.org (duke)
Date: Mon, 22 Jul 2024 13:05:36 GMT
Subject: <i18n dev> RFR: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation [v5]
In-Reply-To: <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
 <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com>
Message-ID: <jsso3K0jWKVjVyc9wooDnV6JEFdY7Z_8K1iTJrWIQMg=.7878a7ef-06b4-453f-96c1-d8916a2ad789@github.com>

On Sun, 21 Jul 2024 21:15:03 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
>> 
>> It's mostly fixing some relative links.
>> If using `{@docroot}` isn't ideal I can change it.
>> 
>> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
>> 
>> 
>> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
>> 106c106
>> <  <p>
>> ---
>>>  </p>
>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
>> 99c99
>> <  <p>
>> ---
>>> 
>> 106c106
>> <  <p>
>> ---
>>> 
>> 618c618
>> <  <p>
>> ---
>>> 
>> 755c755
>> <  <p>
>> ---
>>> 
>> 783c783
>> < <p>
>> ---
>>> 
>> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
>> 142c142
>> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
>> ---
>>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
>> 120c120
>> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
>> ---
>>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
>> 1420c1420
>> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
>> ---
>>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
>> 1833c1833
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> 1899c1899
>> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
>> ---
>>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
>> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
>> 395c395
>> ...
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo changes to StructuredTaskScope

@nizarbenalla 
Your change (at version 4d5d878491c820db275c7a41611c91cead6fe968) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20251#issuecomment-2242907908

From nbenalla at openjdk.org  Mon Jul 22 13:29:37 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 22 Jul 2024 13:29:37 GMT
Subject: <i18n dev> Integrated: 8336039: Doccheck: HTML warnings,
 broken links and missing files in java.base documentation
In-Reply-To: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com>
Message-ID: <HyKwdAJNYxjr_igTRlQVBOz8Ze5CN_er_WwPwjbqgFo=.04b70756-b773-4213-826f-bfa178002ad1@github.com>

On Fri, 19 Jul 2024 11:11:38 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
> 
> It's mostly fixing some relative links.
> If using `{@docroot}` isn't ideal I can change it.
> 
> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes 
> 
> 
> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html
> 106c106
> <  <p>
> ---
>>  </p>
> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html
> 99c99
> <  <p>
> ---
>> 
> 106c106
> <  <p>
> ---
>> 
> 618c618
> <  <p>
> ---
>> 
> 755c755
> <  <p>
> ---
>> 
> 783c783
> < <p>
> ---
>> 
> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html
> 142c142
> <  the segments allocated by it) becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
> ---
>>  the segments allocated by it) becomes <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>,
> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html
> 120c120
> <  as long as it is <a href="../../../java/lang/ref/package.html#reachability">reachable</a>.
> ---
>>  as long as it is <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>.
> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html
> 1420c1420
> <           kept <a href="../../../java/lang/ref/package.html#reachability">reachable</a>
> ---
>>           kept <a href="../../../java/lang/ref/package-summary.html#reachability">reachable</a>
> 1833c1833
> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
> ---
>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
> 1899c1899
> <           <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>.
> ---
>>           <a href="../../../java/lang/ref/package-summary.html#reachability">unreachable</a>.
> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html
> 395c395
> <  <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>. The
> ---
>>  <a href="../../../j...

This pull request has now been integrated.

Changeset: 92de2b2d
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92de2b2d5f21af38380b437af51e49c7ac142258
Stats:     20 lines in 8 files changed: 0 ins; 1 del; 19 mod

8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation

Reviewed-by: liach, djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/20251

From rriggs at openjdk.org  Mon Jul 22 14:39:33 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 22 Jul 2024 14:39:33 GMT
Subject: <i18n dev> =?utf-8?b?UkZSOiA4MzM1NzkxOiBTcGVlZCDigIvigIt1cCBq?=
 =?utf-8?b?LnUuRm9ybWF0dGVyICYgU3RyaW5nLmZvcm1hdCBbdjRd?=
In-Reply-To: <hGJeZFind-4U7DFNVShiFE0xDqSvikSH_SXt9aBRhXc=.05cc29eb-d01b-4481-aeac-28f68b89579c@github.com>
References: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
 <hGJeZFind-4U7DFNVShiFE0xDqSvikSH_SXt9aBRhXc=.05cc29eb-d01b-4481-aeac-28f68b89579c@github.com>
Message-ID: <6b4c8DgAevLYWryQiG9bhGlmVdddapMQEgoCqORbbEU=.d7dd2b19-0f89-46f2-992b-e45f923fe84a@github.com>

On Sat, 6 Jul 2024 00:15:04 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently.
>> 
>> 
>> Improved performance includes the following:
>> 
>> ## 1. Write directly during the parse process to reduce object allocation.
>> 
>> In the current Formatter implementation, some objects do not need to be allocated, such as:
>> 
>> 
>> class Formatter {
>>     public Formatter format(Locale l, String format, Object ... args) {
>>     	List<FormatString> fsa = parse(format);
>>     	// ...
>>     }
>> 
>>     static List<FormatString> parse(String s) {
>>     	ArrayList<FormatString> al = new ArrayList<>();
>> 
>>         while (i < max) {
>>             int n = s.indexOf('%', i);
>>             if (n < 0) {
>>                 // 
>>                 al.add(new FixedString(s, i, max));
>>             }
>>         }
>>     }
>> }
>> 
>> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List<FormatString> fsa` to store it.
>> 
>> ## 2. Fast path print
>> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method.
>> 
>> ## 3. String.format directly calls j.u.Formatter
>> String.format directly calls j.u.Formatter via SharedSecrets to improve performance
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implementing JavaUtilFormatterAccess using anonymous class

Re-designing the formatting implementation should wait for the re-emergence of the templates project and implementation. It has similar performance goals and it would be beneficial to have a single implementation of the lower levels to avoid code duplication and take advantage of the optimizations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20055#issuecomment-2243122522

From darcy at openjdk.org  Tue Jul 23 02:26:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 Jul 2024 02:26:31 GMT
Subject: <i18n dev> RFR: 8317980: Optimization for Integer.parseInt and
 Long.parseLong [v2]
In-Reply-To: <rGqTfS2h6uN1SJfgHLgLiaFOTu5DMGvEGErO06_Gvmk=.783ffe86-cee8-473b-8b9e-c47610d8f219@github.com>
References: <tc-wIpp8PRgt_KxxoJ8LMiLTYFXA3yTZ-ypI4aK4ttM=.dd9adc4a-b350-41c4-ab21-eeb74ac0ba35@github.com>
 <rGqTfS2h6uN1SJfgHLgLiaFOTu5DMGvEGErO06_Gvmk=.783ffe86-cee8-473b-8b9e-c47610d8f219@github.com>
Message-ID: <xTS7ewNCJGig1x-rbyBPYED4d51McyT_RWMfGqAbR8o=.48f9983f-72e8-4624-962e-dbac2d2c90cc@github.com>

On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method.
>> 
>> The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce changes

src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 255:

> 253:     }
> 254: 
> 255:     @Stable

Please add a textual description of the semantics of this array.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20168#discussion_r1687337615

From duke at openjdk.org  Tue Jul 23 02:37:09 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 23 Jul 2024 02:37:09 GMT
Subject: <i18n dev> RFR: 8317980: Optimization for Integer.parseInt and
 Long.parseLong [v3]
In-Reply-To: <tc-wIpp8PRgt_KxxoJ8LMiLTYFXA3yTZ-ypI4aK4ttM=.dd9adc4a-b350-41c4-ab21-eeb74ac0ba35@github.com>
References: <tc-wIpp8PRgt_KxxoJ8LMiLTYFXA3yTZ-ypI4aK4ttM=.dd9adc4a-b350-41c4-ab21-eeb74ac0ba35@github.com>
Message-ID: <QWfDos-G_UOk4k-3hZ9MMZ494P0I4hHpnS-PpAWqHh0=.8edef1a0-7095-461e-b073-08f27a53fabd@github.com>

> Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method.
> 
> The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add description for DECIMAL_DIGITS

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20168/files
  - new: https://git.openjdk.org/jdk/pull/20168/files/e2cbf4a0..19d6f04b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20168&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20168&range=01-02

  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20168.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20168/head:pull/20168

PR: https://git.openjdk.org/jdk/pull/20168

From duke at openjdk.org  Tue Jul 23 02:48:56 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 23 Jul 2024 02:48:56 GMT
Subject: <i18n dev> RFR: 8317980: Optimization for Integer.parseInt and
 Long.parseLong [v4]
In-Reply-To: <tc-wIpp8PRgt_KxxoJ8LMiLTYFXA3yTZ-ypI4aK4ttM=.dd9adc4a-b350-41c4-ab21-eeb74ac0ba35@github.com>
References: <tc-wIpp8PRgt_KxxoJ8LMiLTYFXA3yTZ-ypI4aK4ttM=.dd9adc4a-b350-41c4-ab21-eeb74ac0ba35@github.com>
Message-ID: <L3_IsNQ19zHuB7ycVYN7DIytFhC_yanXu_tKyjz8JWI=.5413ebeb-5c38-4287-9391-41b6e9a40ed7@github.com>

> Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method.
> 
> The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add description for DECIMAL_DIGITS

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20168/files
  - new: https://git.openjdk.org/jdk/pull/20168/files/19d6f04b..73d5e6a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20168&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20168&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20168.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20168/head:pull/20168

PR: https://git.openjdk.org/jdk/pull/20168

From jlu at openjdk.org  Tue Jul 23 17:32:59 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 Jul 2024 17:32:59 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in NumberFormat
 classes
Message-ID: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>

As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability.

As this is simply cleanup, there is no regression test added.

-------------

Commit messages:
 - add null case to restore IAE behavior
 - init

Changes: https://git.openjdk.org/jdk/pull/20302/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20302&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336847
  Stats: 142 lines in 3 files changed: 0 ins; 29 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/20302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20302/head:pull/20302

PR: https://git.openjdk.org/jdk/pull/20302

From jlu at openjdk.org  Tue Jul 23 17:33:00 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 Jul 2024 17:33:00 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in
 NumberFormat classes
In-Reply-To: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
Message-ID: <_gTi8uxpBKSkA4VFGtGSl_XaNosTeDV7MquWa0enObE=.0684393a-b0c0-49db-9592-74ee39bc0711@github.com>

On Tue, 23 Jul 2024 17:28:02 GMT, Justin Lu <jlu at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability.
> 
> As this is simply cleanup, there is no regression test added.

src/java.base/share/classes/java/text/DecimalFormat.java line 1797:

> 1795:             case Long l -> digitList.set(isNegative, l, maxDigits);
> 1796:             case BigInteger bi -> digitList.set(isNegative, bi, maxDigits);
> 1797:             default -> {} // do nothing

default case could also be thrown `AssertionError` if preferred.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20302#discussion_r1688449249

From liach at openjdk.org  Tue Jul 23 17:53:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 Jul 2024 17:53:33 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in
 NumberFormat classes
In-Reply-To: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
Message-ID: <18zx-9IHjZjtxns_Jsevp_L2uaM0Q9Fnr_vVEp1CuAE=.f26493f2-7bf8-42a9-a451-134c7b469e54@github.com>

On Tue, 23 Jul 2024 17:28:02 GMT, Justin Lu <jlu at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability.
> 
> As this is simply cleanup, there is no regression test added.

Appears to be an equivalent migration by naked eye.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20302#pullrequestreview-2194666920

From jlu at openjdk.org  Tue Jul 23 18:00:41 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 Jul 2024 18:00:41 GMT
Subject: <i18n dev> RFR: 8336787: Examine java.text.Format API for implSpec
 usage
Message-ID: <-hhNAfchsyqjKpXmqPa6twkyEZsTHI8K_yFHYS75WU0=.1fdcebc9-4cd6-41f9-bc2c-7a42d94fa202@github.com>

As discussed in https://bugs.openjdk.org/browse/JDK-8335834, there are occurrences in the java.text.Format API that would benefit from the implSpec (and apiNote) tag. 

This is a doc-only change, and a CSR has also been filed.

I did not think "_Subclasses that support fields should override this and create an ..._" sounded right under the `implSpec` tag, and moved it to an `apiNote` tag.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/20303/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20303&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336787
  Stats: 11 lines in 1 file changed: 5 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20303/head:pull/20303

PR: https://git.openjdk.org/jdk/pull/20303

From liach at openjdk.org  Tue Jul 23 18:00:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 Jul 2024 18:00:41 GMT
Subject: <i18n dev> RFR: 8336787: Examine java.text.Format API for
 implSpec usage
In-Reply-To: <-hhNAfchsyqjKpXmqPa6twkyEZsTHI8K_yFHYS75WU0=.1fdcebc9-4cd6-41f9-bc2c-7a42d94fa202@github.com>
References: <-hhNAfchsyqjKpXmqPa6twkyEZsTHI8K_yFHYS75WU0=.1fdcebc9-4cd6-41f9-bc2c-7a42d94fa202@github.com>
Message-ID: <QJyQ6XgJerJahpk-_XAsGzVpNs6KHA0ZQtS_wHZUeBQ=.b011612a-3a6f-464b-a5b8-78c2a9a31637@github.com>

On Tue, 23 Jul 2024 17:51:04 GMT, Justin Lu <jlu at openjdk.org> wrote:

> As discussed in https://bugs.openjdk.org/browse/JDK-8335834, there are occurrences in the java.text.Format API that would benefit from the implSpec (and apiNote) tag. 
> 
> This is a doc-only change, and a CSR has also been filed.
> 
> I did not think "_Subclasses that support fields should override this and create an ..._" sounded right under the `implSpec` tag, and moved it to an `apiNote` tag.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20303#pullrequestreview-2194680165

From naoto at openjdk.org  Tue Jul 23 18:07:31 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 23 Jul 2024 18:07:31 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in
 NumberFormat classes
In-Reply-To: <_gTi8uxpBKSkA4VFGtGSl_XaNosTeDV7MquWa0enObE=.0684393a-b0c0-49db-9592-74ee39bc0711@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
 <_gTi8uxpBKSkA4VFGtGSl_XaNosTeDV7MquWa0enObE=.0684393a-b0c0-49db-9592-74ee39bc0711@github.com>
Message-ID: <vFLcXTrm5vUjwCiqYkcBBx0RT5ciDWaxz8Q77cqhwV0=.f9172bd8-8a70-495f-b3bb-38dbd0d01ced@github.com>

On Tue, 23 Jul 2024 17:29:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability.
>> 
>> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration).
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 1797:
> 
>> 1795:             case Long l -> digitList.set(isNegative, l, maxDigits);
>> 1796:             case BigInteger bi -> digitList.set(isNegative, bi, maxDigits);
>> 1797:             default -> {} // do nothing
> 
> default case could also be thrown `AssertionError` if preferred.

Or a simple `assert` statement, as throwing an Error could change the behavior

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20302#discussion_r1688492608

From jlu at openjdk.org  Tue Jul 23 18:36:31 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 Jul 2024 18:36:31 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in
 NumberFormat classes
In-Reply-To: <vFLcXTrm5vUjwCiqYkcBBx0RT5ciDWaxz8Q77cqhwV0=.f9172bd8-8a70-495f-b3bb-38dbd0d01ced@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
 <_gTi8uxpBKSkA4VFGtGSl_XaNosTeDV7MquWa0enObE=.0684393a-b0c0-49db-9592-74ee39bc0711@github.com>
 <vFLcXTrm5vUjwCiqYkcBBx0RT5ciDWaxz8Q77cqhwV0=.f9172bd8-8a70-495f-b3bb-38dbd0d01ced@github.com>
Message-ID: <LNwN15xFJww5RDcSLyJVcyGGUoFBdvv51JEhHCdE_7U=.a4dc1ec3-2427-42ff-b2d3-b86243fb68bf@github.com>

On Tue, 23 Jul 2024 18:04:54 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DecimalFormat.java line 1797:
>> 
>>> 1795:             case Long l -> digitList.set(isNegative, l, maxDigits);
>>> 1796:             case BigInteger bi -> digitList.set(isNegative, bi, maxDigits);
>>> 1797:             default -> {} // do nothing
>> 
>> default case could also be thrown `AssertionError` if preferred.
>
> Or a simple `assert` statement, as throwing an Error could change the behavior

Either of the 3 is fine with me. In this case, I think `AssertionError` is harmless, because AFAICT it is internally used by CompactNumberFormat only, and so throwing may prevent potential incorrect uses in the future.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20302#discussion_r1688523933

From naoto at openjdk.org  Tue Jul 23 18:51:31 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 23 Jul 2024 18:51:31 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in
 NumberFormat classes
In-Reply-To: <LNwN15xFJww5RDcSLyJVcyGGUoFBdvv51JEhHCdE_7U=.a4dc1ec3-2427-42ff-b2d3-b86243fb68bf@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
 <_gTi8uxpBKSkA4VFGtGSl_XaNosTeDV7MquWa0enObE=.0684393a-b0c0-49db-9592-74ee39bc0711@github.com>
 <vFLcXTrm5vUjwCiqYkcBBx0RT5ciDWaxz8Q77cqhwV0=.f9172bd8-8a70-495f-b3bb-38dbd0d01ced@github.com>
 <LNwN15xFJww5RDcSLyJVcyGGUoFBdvv51JEhHCdE_7U=.a4dc1ec3-2427-42ff-b2d3-b86243fb68bf@github.com>
Message-ID: <1n6UejgupVDVyENpehwB71gcpr_hYKxqiMkukZckF2g=.b7dd82ac-d420-43d4-8fa8-a610d9f938d3@github.com>

On Tue, 23 Jul 2024 18:33:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Or a simple `assert` statement, as throwing an Error could change the behavior
>
> Either of the 3 is fine with me. In this case, I think `AssertionError` is harmless, because AFAICT it is internally used by CompactNumberFormat only, and so throwing may prevent potential incorrect uses in the future.

OK, then I think I am inclined to use `AssertionError`, assuming `DigitList` is defined to only accept those types. Might want to modify the method description too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20302#discussion_r1688543808

From duke at openjdk.org  Tue Jul 23 19:54:30 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Tue, 23 Jul 2024 19:54:30 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in
 NumberFormat classes
In-Reply-To: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
Message-ID: <gtvzZmlNVHqCGw7aB97GHmyPgUkRNO8jrJPsZK387eE=.1e1633af-9ba2-4549-8c6d-d5115653dbc9@github.com>

On Tue, 23 Jul 2024 17:28:02 GMT, Justin Lu <jlu at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability.
> 
> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration).

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20302#pullrequestreview-2194939999

From jlu at openjdk.org  Tue Jul 23 20:54:08 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 Jul 2024 20:54:08 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in
 NumberFormat classes [v2]
In-Reply-To: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
Message-ID: <my7lINCD0XPBGEOoOLoEJnN480rBRWnn_O0NAeU2Cvc=.a4ebb9ca-2493-42a8-982f-75c9f45ebc3d@github.com>

> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability.
> 
> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration).

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20302/files
  - new: https://git.openjdk.org/jdk/pull/20302/files/2efa5d3f..7799b0a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20302&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20302&range=00-01

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20302/head:pull/20302

PR: https://git.openjdk.org/jdk/pull/20302

From liach at openjdk.org  Wed Jul 24 14:18:32 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 Jul 2024 14:18:32 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in
 NumberFormat classes [v2]
In-Reply-To: <my7lINCD0XPBGEOoOLoEJnN480rBRWnn_O0NAeU2Cvc=.a4ebb9ca-2493-42a8-982f-75c9f45ebc3d@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
 <my7lINCD0XPBGEOoOLoEJnN480rBRWnn_O0NAeU2Cvc=.a4ebb9ca-2493-42a8-982f-75c9f45ebc3d@github.com>
Message-ID: <w370X_dS9QcDkX8fpz4SNYi7KvSn9X7GjW3s8zNaeTo=.18bde492-4c72-46c2-a0ba-a05fe48c0b3a@github.com>

On Tue, 23 Jul 2024 20:54:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability.
>> 
>> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

The new AssertionError looks neat.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20302#pullrequestreview-2196887046

From naoto at openjdk.org  Wed Jul 24 16:41:32 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 24 Jul 2024 16:41:32 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in
 NumberFormat classes [v2]
In-Reply-To: <my7lINCD0XPBGEOoOLoEJnN480rBRWnn_O0NAeU2Cvc=.a4ebb9ca-2493-42a8-982f-75c9f45ebc3d@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
 <my7lINCD0XPBGEOoOLoEJnN480rBRWnn_O0NAeU2Cvc=.a4ebb9ca-2493-42a8-982f-75c9f45ebc3d@github.com>
Message-ID: <y5CDfuczLOsPntqWU2yARB2fzM4htDeLNkhvn_hw-Io=.b848c846-c93a-42f1-8fca-1cdf6d2a11ce@github.com>

On Tue, 23 Jul 2024 20:54:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability.
>> 
>> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20302#pullrequestreview-2197263736

From aturbanov at openjdk.org  Wed Jul 24 19:12:32 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 24 Jul 2024 19:12:32 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in
 NumberFormat classes [v2]
In-Reply-To: <my7lINCD0XPBGEOoOLoEJnN480rBRWnn_O0NAeU2Cvc=.a4ebb9ca-2493-42a8-982f-75c9f45ebc3d@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
 <my7lINCD0XPBGEOoOLoEJnN480rBRWnn_O0NAeU2Cvc=.a4ebb9ca-2493-42a8-982f-75c9f45ebc3d@github.com>
Message-ID: <-POXdqDTBpENhdR9sDS36AhVHq0ibmliQGzJIYSYoc4=.63c3ec3e-31e7-42cc-8f33-157e8c603d63@github.com>

On Tue, 23 Jul 2024 20:54:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability.
>> 
>> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

src/java.base/share/classes/java/text/NumberFormat.java line 331:

> 329:             case BigInteger bi when bi.bitLength() < 64 -> format(bi.longValue(), toAppendTo, pos);
> 330:             case Number n -> format(n.doubleValue(), toAppendTo, pos);
> 331:             case null, default  -> throw new IllegalArgumentException("Cannot format given Object as a Number");

Suggestion:

            case null, default -> throw new IllegalArgumentException("Cannot format given Object as a Number");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20302#discussion_r1690303087

From jlu at openjdk.org  Wed Jul 24 19:45:45 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 24 Jul 2024 19:45:45 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in
 NumberFormat classes [v3]
In-Reply-To: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
Message-ID: <dFX4kXSvSZyKP8kgYvnS07NETPtvEcuXZxpky9tYKa0=.253c4cd5-9e35-4aa2-adab-3c8e82c2d12b@github.com>

> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability.
> 
> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration).

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20302/files
  - new: https://git.openjdk.org/jdk/pull/20302/files/7799b0a6..e9f24bc4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20302&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20302&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20302/head:pull/20302

PR: https://git.openjdk.org/jdk/pull/20302

From naoto at openjdk.org  Wed Jul 24 19:55:32 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 24 Jul 2024 19:55:32 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in
 NumberFormat classes [v3]
In-Reply-To: <dFX4kXSvSZyKP8kgYvnS07NETPtvEcuXZxpky9tYKa0=.253c4cd5-9e35-4aa2-adab-3c8e82c2d12b@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
 <dFX4kXSvSZyKP8kgYvnS07NETPtvEcuXZxpky9tYKa0=.253c4cd5-9e35-4aa2-adab-3c8e82c2d12b@github.com>
Message-ID: <78HewAa5utrky-gZR1fZPoy9hZiUKlRbAnTq6qRDK9k=.55d30f4a-b829-4f41-bcb7-8307b1a9914d@github.com>

On Wed, 24 Jul 2024 19:45:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability.
>> 
>> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comment

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20302#pullrequestreview-2197643624

From liach at openjdk.org  Wed Jul 24 20:10:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 Jul 2024 20:10:33 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in
 NumberFormat classes [v3]
In-Reply-To: <dFX4kXSvSZyKP8kgYvnS07NETPtvEcuXZxpky9tYKa0=.253c4cd5-9e35-4aa2-adab-3c8e82c2d12b@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
 <dFX4kXSvSZyKP8kgYvnS07NETPtvEcuXZxpky9tYKa0=.253c4cd5-9e35-4aa2-adab-3c8e82c2d12b@github.com>
Message-ID: <bLpG8-6ntP1IoGJEX7FC36Gai6FLzp_5i8lWKKlS0Vg=.59c546bb-c750-4e1e-b801-cbeb48dd5a47@github.com>

On Wed, 24 Jul 2024 19:45:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability.
>> 
>> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comment

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20302#pullrequestreview-2197671975

From jlu at openjdk.org  Wed Jul 24 20:10:35 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 24 Jul 2024 20:10:35 GMT
Subject: <i18n dev> Integrated: 8336787: Examine java.text.Format API for
 implSpec usage
In-Reply-To: <-hhNAfchsyqjKpXmqPa6twkyEZsTHI8K_yFHYS75WU0=.1fdcebc9-4cd6-41f9-bc2c-7a42d94fa202@github.com>
References: <-hhNAfchsyqjKpXmqPa6twkyEZsTHI8K_yFHYS75WU0=.1fdcebc9-4cd6-41f9-bc2c-7a42d94fa202@github.com>
Message-ID: <lvXHbtdJ3CPP3IUCsjUHqjRAFxhpwr89Yv0Wryk0dp4=.47ffce48-e459-40ff-8471-08504e9c3058@github.com>

On Tue, 23 Jul 2024 17:51:04 GMT, Justin Lu <jlu at openjdk.org> wrote:

> As discussed in https://bugs.openjdk.org/browse/JDK-8335834, there are occurrences in the java.text.Format API that would benefit from the implSpec (and apiNote) tag. 
> 
> This is a doc-only change, and a CSR has also been filed.
> 
> I did not think "_Subclasses that support fields should override this and create an ..._" sounded right under the `implSpec` tag, and moved it to an `apiNote` tag.

This pull request has now been integrated.

Changeset: 9e8e3595
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e8e359513cf15faf549b12ced947d3a78e544aa
Stats:     11 lines in 1 file changed: 5 ins; 5 del; 1 mod

8336787: Examine java.text.Format API for implSpec usage

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/20303

From jlu at openjdk.org  Wed Jul 24 20:16:37 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 24 Jul 2024 20:16:37 GMT
Subject: <i18n dev> RFR: 8336847: Use pattern match switch in
 NumberFormat classes [v3]
In-Reply-To: <dFX4kXSvSZyKP8kgYvnS07NETPtvEcuXZxpky9tYKa0=.253c4cd5-9e35-4aa2-adab-3c8e82c2d12b@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
 <dFX4kXSvSZyKP8kgYvnS07NETPtvEcuXZxpky9tYKa0=.253c4cd5-9e35-4aa2-adab-3c8e82c2d12b@github.com>
Message-ID: <t4p145Te74Du2J6H5ni0Bw20yV-wR5rHYunzkxMmkR8=.81008ab3-416a-4686-8568-044dd7bbc291@github.com>

On Wed, 24 Jul 2024 19:45:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability.
>> 
>> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comment

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20302#issuecomment-2248817446

From jlu at openjdk.org  Wed Jul 24 20:16:37 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 24 Jul 2024 20:16:37 GMT
Subject: <i18n dev> Integrated: 8336847: Use pattern match switch in
 NumberFormat classes
In-Reply-To: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
References: <RLGPuitwVvT35KZVXUiKWVXT2YSa12coplcIbsOV88Y=.fced4a1f-2098-431c-87b1-ef05849fad99@github.com>
Message-ID: <fcZfclaUUu3xfgDC4ASQLRxw9K8SMxhmu9BQWBOMqa0=.139fff7a-bce4-4ac7-a261-1b514c0cbb00@github.com>

On Tue, 23 Jul 2024 17:28:02 GMT, Justin Lu <jlu at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability.
> 
> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration).

This pull request has now been integrated.

Changeset: 5a8861a3
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a8861a3a1b436ce7414176c095c58c9a1e038d6
Stats:     146 lines in 3 files changed: 3 ins; 28 del; 115 mod

8336847: Use pattern match switch in NumberFormat classes

Reviewed-by: liach, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/20302

From jlu at openjdk.org  Thu Jul 25 22:23:45 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 25 Jul 2024 22:23:45 GMT
Subject: <i18n dev> RFR: 8313205: Modernize java.text.Format with
 StringBuilder
Message-ID: <pcp8sniMJo1xfOi4YfMgyd3vXhE1-w6AKGU_FBbPLQI=.6160525d-5e8c-40bd-879d-1664ff470abb@github.com>

Please review this PR which adds public StringBuilder overloads to the formatting methods of java.text.Format and implementing subclasses.

While Format, NumberFormat, and DateFormat are abstract, these new methods are not added as abstract to prevent compatibility concerns. Instead they are added as non-abstract methods, with a default implementation that throws UOE and a recommendation that subclasses override and provide their own implementations. These new methods use the same specification as the StringBuffer ones, with exception of `MessageFormat.format(format(Object[] arguments, StringBuilder result, FieldPosition pos)` which omits the table, and instead links to it.

The JDK implementing Format classes, (such as DecimalFormat) leverage the StringBuf proxy methods.

A corresponding CSR has been drafted: https://bugs.openjdk.org/browse/JDK-8337141, which goes into detail on motivation/history. (Holding off on uploading the specification to CSR until wording finalized).

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/20337/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20337&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313205
  Stats: 883 lines in 12 files changed: 881 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20337/head:pull/20337

PR: https://git.openjdk.org/jdk/pull/20337

From liach at openjdk.org  Thu Jul 25 23:31:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 25 Jul 2024 23:31:36 GMT
Subject: <i18n dev> RFR: 8313205: Modernize java.text.Format with
 StringBuilder
In-Reply-To: <pcp8sniMJo1xfOi4YfMgyd3vXhE1-w6AKGU_FBbPLQI=.6160525d-5e8c-40bd-879d-1664ff470abb@github.com>
References: <pcp8sniMJo1xfOi4YfMgyd3vXhE1-w6AKGU_FBbPLQI=.6160525d-5e8c-40bd-879d-1664ff470abb@github.com>
Message-ID: <CL6bJp-2e75QPQUjrocMvYvCRf0TUiDXYhaBkqf2TUU=.912e9b25-ea1f-4d96-a74d-10444a09ce9a@github.com>

On Thu, 25 Jul 2024 22:18:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds public StringBuilder overloads to the formatting methods of java.text.Format and implementing subclasses.
> 
> While Format, NumberFormat, and DateFormat are abstract, these new methods are not added as abstract to prevent compatibility concerns. Instead they are added as non-abstract methods, with a default implementation that throws UOE and a recommendation that subclasses override and provide their own implementations. These new methods use the same specification as the StringBuffer ones, with exception of `MessageFormat.format(format(Object[] arguments, StringBuilder result, FieldPosition pos)` which omits the table, and instead links to it.
> 
> The JDK implementing Format classes, (such as DecimalFormat) leverage the StringBuf proxy methods.
> 
> A corresponding CSR has been drafted: https://bugs.openjdk.org/browse/JDK-8337141, which goes into detail on motivation/history. (Holding off on uploading the specification to CSR until wording finalized).

You should add `@since` tags on all these new API additions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20337#issuecomment-2251565706

From jlu at openjdk.org  Thu Jul 25 23:45:08 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 25 Jul 2024 23:45:08 GMT
Subject: <i18n dev> RFR: 8313205: Modernize java.text.Format with
 StringBuilder [v2]
In-Reply-To: <pcp8sniMJo1xfOi4YfMgyd3vXhE1-w6AKGU_FBbPLQI=.6160525d-5e8c-40bd-879d-1664ff470abb@github.com>
References: <pcp8sniMJo1xfOi4YfMgyd3vXhE1-w6AKGU_FBbPLQI=.6160525d-5e8c-40bd-879d-1664ff470abb@github.com>
Message-ID: <4K4AeUzxdLsAsgIcxZ02d4jLhQUMbCXrmKtjuN2yzIk=.5ea419d8-948b-4121-953d-805659c09e37@github.com>

> Please review this PR which adds public StringBuilder overloads to the formatting methods of java.text.Format and implementing subclasses.
> 
> While Format, NumberFormat, and DateFormat are abstract, these new methods are not added as abstract to prevent compatibility concerns. Instead they are added as non-abstract methods, with a default implementation that throws UOE and a recommendation that subclasses override and provide their own implementations. These new methods use the same specification as the StringBuffer ones, with exception of `MessageFormat.format(format(Object[] arguments, StringBuilder result, FieldPosition pos)` which omits the table, and instead links to it.
> 
> The JDK implementing Format classes, (such as DecimalFormat) leverage the StringBuf proxy methods.
> 
> A corresponding CSR has been drafted: https://bugs.openjdk.org/browse/JDK-8337141, which goes into detail on motivation/history. (Holding off on uploading the specification to CSR until wording finalized).

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  add since tags

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20337/files
  - new: https://git.openjdk.org/jdk/pull/20337/files/3c78d9ac..314b8d7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20337&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20337&range=00-01

  Stats: 18 lines in 9 files changed: 18 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20337/head:pull/20337

PR: https://git.openjdk.org/jdk/pull/20337

From jlu at openjdk.org  Thu Jul 25 23:45:08 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 25 Jul 2024 23:45:08 GMT
Subject: <i18n dev> RFR: 8313205: Modernize java.text.Format with
 StringBuilder
In-Reply-To: <CL6bJp-2e75QPQUjrocMvYvCRf0TUiDXYhaBkqf2TUU=.912e9b25-ea1f-4d96-a74d-10444a09ce9a@github.com>
References: <pcp8sniMJo1xfOi4YfMgyd3vXhE1-w6AKGU_FBbPLQI=.6160525d-5e8c-40bd-879d-1664ff470abb@github.com>
 <CL6bJp-2e75QPQUjrocMvYvCRf0TUiDXYhaBkqf2TUU=.912e9b25-ea1f-4d96-a74d-10444a09ce9a@github.com>
Message-ID: <nNeu2RUFPUR90H8mwMc_md1nbRYGIIhwkxsI0e9X9dY=.730cbd11-714a-4cba-8312-68cb5d713e3b@github.com>

On Thu, 25 Jul 2024 23:28:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> You should add `@since` tags on all these new API additions.

Thanks for the reminder. Updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20337#issuecomment-2251577718

From duke at openjdk.org  Fri Jul 26 14:29:45 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 26 Jul 2024 14:29:45 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant
Message-ID: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>

By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.

-------------

Commit messages:
 - optimize format instant

Changes: https://git.openjdk.org/jdk/pull/20353/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337279
  Stats: 43 lines in 2 files changed: 7 ins; 31 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20353.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20353/head:pull/20353

PR: https://git.openjdk.org/jdk/pull/20353

From duke at openjdk.org  Fri Jul 26 14:29:45 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 26 Jul 2024 14:29:45 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant
In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
Message-ID: <ROTHPoCTCAVaOp3_NbI1ISzjdvdZJUc3xHAhHGUicAk=.de8c96df-b68a-47fe-b006-f1c5847e247b@github.com>

On Fri, 26 Jul 2024 14:20:07 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.

By removing redundant code logic, the codeSize can be reduced from 444 to 240, and the performance is improved.

Below are the performance numbers running on MacBook M1 Pro


-# master 5ff7c57f9ff5428ef3d2aedd7e860bb1e8ff29ea
-Benchmark                       Mode  Cnt  Score   Error   Units
-ToStringBench.instantToString  thrpt   15  4.734 ? 0.547  ops/ms +24.10%

+# current baf0f9ca83c111401d6e034dfba0ee2c71280e62
+Benchmark                       Mode  Cnt  Score   Error   Units
+ToStringBench.instantToString  thrpt   15  5.875 ? 0.301  ops/ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2252885851

From scolebourne at openjdk.org  Fri Jul 26 15:27:35 2024
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Fri, 26 Jul 2024 15:27:35 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant
In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
Message-ID: <nzFIZC5L68XSclC4G5-pTKxK3nTEdQTfdebZJWEQrzA=.dc5bfa47-5e9f-40fb-81cb-a4661e361f91@github.com>

On Fri, 26 Jul 2024 14:20:07 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3818:

> 3816:             }
> 3817:             // add fraction
> 3818:             if (fractionalDigits > 0) {

This breaks the logic. `fractionalDigits` can be negative in the block below

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1693253379

From duke at openjdk.org  Fri Jul 26 15:34:34 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 26 Jul 2024 15:34:34 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant
In-Reply-To: <nzFIZC5L68XSclC4G5-pTKxK3nTEdQTfdebZJWEQrzA=.dc5bfa47-5e9f-40fb-81cb-a4661e361f91@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <nzFIZC5L68XSclC4G5-pTKxK3nTEdQTfdebZJWEQrzA=.dc5bfa47-5e9f-40fb-81cb-a4661e361f91@github.com>
Message-ID: <hZtN4RXWWLNKHNU6Qgq3z0vGcdEDC4gDWCn5fhzXWiY=.0639017a-a3e8-4abf-ae5c-08dc16e04bd5@github.com>

On Fri, 26 Jul 2024 15:24:46 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3818:
> 
>> 3816:             }
>> 3817:             // add fraction
>> 3818:             if (fractionalDigits > 0) {
> 
> This breaks the logic. `fractionalDigits` can be negative in the block below

If fractionalDigits < 0, printNano is implemented in LocalDateTime

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1693263366

From duke at openjdk.org  Fri Jul 26 15:44:59 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 26 Jul 2024 15:44:59 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v2]
In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
Message-ID: <0rRenYTABuRAzJxLQ7llecvge7VUEUab5wU_M78_e5c=.88b3b0c7-f6e2-4dfa-bbf8-3820fdf43e5d@github.com>

> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20353/files
  - new: https://git.openjdk.org/jdk/pull/20353/files/baf0f9ca..64403d5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20353.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20353/head:pull/20353

PR: https://git.openjdk.org/jdk/pull/20353

From duke at openjdk.org  Fri Jul 26 15:55:34 2024
From: duke at openjdk.org (Andriy Plokhotnyuk)
Date: Fri, 26 Jul 2024 15:55:34 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v2]
In-Reply-To: <0rRenYTABuRAzJxLQ7llecvge7VUEUab5wU_M78_e5c=.88b3b0c7-f6e2-4dfa-bbf8-3820fdf43e5d@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <0rRenYTABuRAzJxLQ7llecvge7VUEUab5wU_M78_e5c=.88b3b0c7-f6e2-4dfa-bbf8-3820fdf43e5d@github.com>
Message-ID: <ts5xu5DuSJOyEgJeMUO40eDyG1Aando4jibuDfE01DU=.3878fedb-3f0e-4b97-9f87-51f455ae74c7@github.com>

On Fri, 26 Jul 2024 15:44:59 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comment

@jodastephen @wenshao Could you please review [these](https://github.com/openjdk/jdk/pull/11986) proposed changes for instantiation of `Instant` values with already normalized nanos?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2253044743

From rriggs at openjdk.org  Fri Jul 26 18:05:35 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 Jul 2024 18:05:35 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v2]
In-Reply-To: <ts5xu5DuSJOyEgJeMUO40eDyG1Aando4jibuDfE01DU=.3878fedb-3f0e-4b97-9f87-51f455ae74c7@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <0rRenYTABuRAzJxLQ7llecvge7VUEUab5wU_M78_e5c=.88b3b0c7-f6e2-4dfa-bbf8-3820fdf43e5d@github.com>
 <ts5xu5DuSJOyEgJeMUO40eDyG1Aando4jibuDfE01DU=.3878fedb-3f0e-4b97-9f87-51f455ae74c7@github.com>
Message-ID: <OFz7ISGQy3izyS5XEFoe7uTrcfxj9JCo_FueS1YRnM4=.67fa807f-9cc1-4d70-81e8-c25692a12377@github.com>

On Fri, 26 Jul 2024 15:53:11 GMT, Andriy Plokhotnyuk <duke at openjdk.org> wrote:

> Could you please review [these](https://github.com/openjdk/jdk/pull/11986) proposed changes for instantiation of `Instant` values with already normalized nanos?

@plokhotnyuk Your contribution cannot be acted upon until the OCA is confirmed.
If you have not submitted an OCA, please do so. See https://oca.opensource.oracle.com/

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2253234822

From jlu at openjdk.org  Fri Jul 26 19:21:39 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 26 Jul 2024 19:21:39 GMT
Subject: <i18n dev> RFR: 8337285: Examine java.text.DecimalFormat API for
 api/implXxx tag usage
Message-ID: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>

Please review this PR which is a simple doc only change to java.text.DecimalFormat.

Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well.

A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/20361/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20361&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337285
  Stats: 43 lines in 1 file changed: 13 ins; 16 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/20361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20361/head:pull/20361

PR: https://git.openjdk.org/jdk/pull/20361

From naoto at openjdk.org  Fri Jul 26 20:09:31 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Jul 2024 20:09:31 GMT
Subject: <i18n dev> RFR: 8337285: Examine java.text.DecimalFormat API
 for api/implXxx tag usage
In-Reply-To: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
References: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
Message-ID: <p1UKMks35sB2ZHb6hLfrsKnVFnYs-Djgz7gd1hjIxs0=.d382ec38-6cd3-42db-bce7-4ae73410297f@github.com>

On Fri, 26 Jul 2024 19:17:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a simple doc only change to java.text.DecimalFormat.
> 
> Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well.
> 
> A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted.

src/java.base/share/classes/java/text/DecimalFormat.java line 441:

> 439:      * @see NumberFormat#getNumberInstance()
> 440:      * @see NumberFormat#getCurrencyInstance()
> 441:      * @see NumberFormat#getPercentInstance()

The paragraph is for a "given" locale, probably factories that take Locale would be more appropriate than no-arg ones. (applies to other locations too)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20361#discussion_r1693536829

From jlu at openjdk.org  Fri Jul 26 20:45:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 26 Jul 2024 20:45:43 GMT
Subject: <i18n dev> RFR: 8337285: Examine java.text.DecimalFormat API
 for api/implXxx tag usage [v2]
In-Reply-To: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
References: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
Message-ID: <7vGY09-oOSMdnpjiX2n5YziB4QrixDZQr3n4dZw6bdE=.f8212f3e-1793-43bc-b330-9f860e675702@github.com>

> Please review this PR which is a simple doc only change to java.text.DecimalFormat.
> 
> Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well.
> 
> A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20361/files
  - new: https://git.openjdk.org/jdk/pull/20361/files/562a44ed..c16bfab1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20361&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20361&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20361/head:pull/20361

PR: https://git.openjdk.org/jdk/pull/20361

From jlu at openjdk.org  Fri Jul 26 20:45:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 26 Jul 2024 20:45:43 GMT
Subject: <i18n dev> RFR: 8337285: Examine java.text.DecimalFormat API
 for api/implXxx tag usage [v2]
In-Reply-To: <p1UKMks35sB2ZHb6hLfrsKnVFnYs-Djgz7gd1hjIxs0=.d382ec38-6cd3-42db-bce7-4ae73410297f@github.com>
References: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
 <p1UKMks35sB2ZHb6hLfrsKnVFnYs-Djgz7gd1hjIxs0=.d382ec38-6cd3-42db-bce7-4ae73410297f@github.com>
Message-ID: <dlulnBAkyBKFSyzbT9_4n66RBmteNKSsNWU-mI7Kf9E=.5177b01f-6b67-4d9d-8d37-2349835d98e4@github.com>

On Fri, 26 Jul 2024 20:05:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect review
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 441:
> 
>> 439:      * @see NumberFormat#getNumberInstance()
>> 440:      * @see NumberFormat#getCurrencyInstance()
>> 441:      * @see NumberFormat#getPercentInstance()
> 
> The paragraph is for a "given" locale, probably factories that take Locale would be more appropriate than no-arg ones. (applies to other locations too)

I picked the no-arg methods because I imagine most users want the default locale instance. But I agree that it makes sense to use the Locale arg methods, since the phrasing does say "given locale" (twice). Updated here and in the other instances, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20361#discussion_r1693589378

From liach at openjdk.org  Fri Jul 26 21:07:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Jul 2024 21:07:31 GMT
Subject: <i18n dev> RFR: 8337285: Examine java.text.DecimalFormat API
 for api/implXxx tag usage [v2]
In-Reply-To: <7vGY09-oOSMdnpjiX2n5YziB4QrixDZQr3n4dZw6bdE=.f8212f3e-1793-43bc-b330-9f860e675702@github.com>
References: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
 <7vGY09-oOSMdnpjiX2n5YziB4QrixDZQr3n4dZw6bdE=.f8212f3e-1793-43bc-b330-9f860e675702@github.com>
Message-ID: <d6txLr6dCXmI_pWqhkl-QxP4Zpmwabwtvgj44OB6dHI=.f2702967-17db-4792-a5e6-d96d7b350e31@github.com>

On Fri, 26 Jul 2024 20:45:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which is a simple doc only change to java.text.DecimalFormat.
>> 
>> Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well.
>> 
>> A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

src/java.base/share/classes/java/text/DecimalFormat.java line 438:

> 436:      * NumberFormat#getNumberInstance(Locale)}. These factories will return the most
> 437:      * appropriate subclass of NumberFormat for a given locale.
> 438:      * @see NumberFormat#getInstance()

Suggestion:

     * @see NumberFormat#getInstance(Locale)

and for other such links. I second @naotoj's remark.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20361#discussion_r1693605351

From jlu at openjdk.org  Fri Jul 26 21:22:58 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 26 Jul 2024 21:22:58 GMT
Subject: <i18n dev> RFR: 8337285: Examine java.text.DecimalFormat API
 for api/implXxx tag usage [v3]
In-Reply-To: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
References: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
Message-ID: <ZqHnujMweA3tOsC7ZLFBPU4nBo6S_Zl3MhVAoxBRXv4=.325f6df7-2ee8-408e-8ecb-b278516ec66f@github.com>

> Please review this PR which is a simple doc only change to java.text.DecimalFormat.
> 
> Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well.
> 
> A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  update see links with Locale arg link

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20361/files
  - new: https://git.openjdk.org/jdk/pull/20361/files/c16bfab1..344d82c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20361&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20361&range=01-02

  Stats: 13 lines in 1 file changed: 1 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/20361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20361/head:pull/20361

PR: https://git.openjdk.org/jdk/pull/20361

From jlu at openjdk.org  Fri Jul 26 21:22:59 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 26 Jul 2024 21:22:59 GMT
Subject: <i18n dev> RFR: 8337285: Examine java.text.DecimalFormat API
 for api/implXxx tag usage [v2]
In-Reply-To: <d6txLr6dCXmI_pWqhkl-QxP4Zpmwabwtvgj44OB6dHI=.f2702967-17db-4792-a5e6-d96d7b350e31@github.com>
References: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
 <7vGY09-oOSMdnpjiX2n5YziB4QrixDZQr3n4dZw6bdE=.f8212f3e-1793-43bc-b330-9f860e675702@github.com>
 <d6txLr6dCXmI_pWqhkl-QxP4Zpmwabwtvgj44OB6dHI=.f2702967-17db-4792-a5e6-d96d7b350e31@github.com>
Message-ID: <Jrqj7tJkmI7GWVaKH_MFov9JwfxECRLDKsiQFj5VF6s=.c551f999-dacf-4716-a8f6-66c3b55da297@github.com>

On Fri, 26 Jul 2024 21:05:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect review
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 438:
> 
>> 436:      * NumberFormat#getNumberInstance(Locale)}. These factories will return the most
>> 437:      * appropriate subclass of NumberFormat for a given locale.
>> 438:      * @see NumberFormat#getInstance()
> 
> Suggestion:
> 
>      * @see NumberFormat#getInstance(Locale)
> 
> and for other such links. I second @naotoj's remark.

Thanks, updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20361#discussion_r1693615845

From liach at openjdk.org  Fri Jul 26 21:26:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Jul 2024 21:26:31 GMT
Subject: <i18n dev> RFR: 8337285: Examine java.text.DecimalFormat API
 for api/implXxx tag usage [v3]
In-Reply-To: <ZqHnujMweA3tOsC7ZLFBPU4nBo6S_Zl3MhVAoxBRXv4=.325f6df7-2ee8-408e-8ecb-b278516ec66f@github.com>
References: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
 <ZqHnujMweA3tOsC7ZLFBPU4nBo6S_Zl3MhVAoxBRXv4=.325f6df7-2ee8-408e-8ecb-b278516ec66f@github.com>
Message-ID: <PRM_3hmy9QioPOEGo-kg9R21FKJHpzcAa_CyCSVC_ds=.206b0966-891a-4d25-92ee-7053e1a2de2d@github.com>

On Fri, 26 Jul 2024 21:22:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which is a simple doc only change to java.text.DecimalFormat.
>> 
>> Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well.
>> 
>> A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update see links with Locale arg link

Thanks for the fixes. Reviewed the up-to-date CSR too.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20361#pullrequestreview-2202768206

From naoto at openjdk.org  Fri Jul 26 22:55:41 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Jul 2024 22:55:41 GMT
Subject: <i18n dev> RFR: 8337285: Examine java.text.DecimalFormat API
 for api/implXxx tag usage [v3]
In-Reply-To: <ZqHnujMweA3tOsC7ZLFBPU4nBo6S_Zl3MhVAoxBRXv4=.325f6df7-2ee8-408e-8ecb-b278516ec66f@github.com>
References: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
 <ZqHnujMweA3tOsC7ZLFBPU4nBo6S_Zl3MhVAoxBRXv4=.325f6df7-2ee8-408e-8ecb-b278516ec66f@github.com>
Message-ID: <qcfBgslUvr5pUUtrwrgmMVracQIcPSsugaI3WomRmGk=.2890bc98-04bf-4ede-922e-dfcd325c56bd@github.com>

On Fri, 26 Jul 2024 21:22:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which is a simple doc only change to java.text.DecimalFormat.
>> 
>> Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well.
>> 
>> A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update see links with Locale arg link

src/java.base/share/classes/java/text/DecimalFormat.java line 478:

> 476:      * @see NumberFormat#getCurrencyInstance(Locale)
> 477:      * @see NumberFormat#getPercentInstance(Locale)
> 478:      * @see NumberFormat#getPercentInstance(Locale)

This seems to be a dup

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20361#discussion_r1693663620

From jlu at openjdk.org  Fri Jul 26 23:02:14 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 26 Jul 2024 23:02:14 GMT
Subject: <i18n dev> RFR: 8337285: Examine java.text.DecimalFormat API
 for api/implXxx tag usage [v4]
In-Reply-To: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
References: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
Message-ID: <ONP6px6r8myr0whjiH5OCJPTGrYdMTfcQVCeQNkTLYs=.44585470-c260-40b0-99da-90043771d95b@github.com>

> Please review this PR which is a simple doc only change to java.text.DecimalFormat.
> 
> Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well.
> 
> A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  remove duplicate

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20361/files
  - new: https://git.openjdk.org/jdk/pull/20361/files/344d82c9..98670109

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20361&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20361&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20361/head:pull/20361

PR: https://git.openjdk.org/jdk/pull/20361

From jlu at openjdk.org  Fri Jul 26 23:02:14 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 26 Jul 2024 23:02:14 GMT
Subject: <i18n dev> RFR: 8337285: Examine java.text.DecimalFormat API
 for api/implXxx tag usage [v3]
In-Reply-To: <qcfBgslUvr5pUUtrwrgmMVracQIcPSsugaI3WomRmGk=.2890bc98-04bf-4ede-922e-dfcd325c56bd@github.com>
References: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
 <ZqHnujMweA3tOsC7ZLFBPU4nBo6S_Zl3MhVAoxBRXv4=.325f6df7-2ee8-408e-8ecb-b278516ec66f@github.com>
 <qcfBgslUvr5pUUtrwrgmMVracQIcPSsugaI3WomRmGk=.2890bc98-04bf-4ede-922e-dfcd325c56bd@github.com>
Message-ID: <-pfU6d7RoajUXUSFVbLqmcb3J45Xdt5eXYCUZD6kfgw=.19696350-ab3e-4d7b-b80e-7c358a90fdc8@github.com>

On Fri, 26 Jul 2024 22:51:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update see links with Locale arg link
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 478:
> 
>> 476:      * @see NumberFormat#getCurrencyInstance(Locale)
>> 477:      * @see NumberFormat#getPercentInstance(Locale)
>> 478:      * @see NumberFormat#getPercentInstance(Locale)
> 
> This seems to be a dup

Removed, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20361#discussion_r1693677723

From naoto at openjdk.org  Fri Jul 26 23:26:41 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Jul 2024 23:26:41 GMT
Subject: <i18n dev> RFR: 8337285: Examine java.text.DecimalFormat API
 for api/implXxx tag usage [v4]
In-Reply-To: <ONP6px6r8myr0whjiH5OCJPTGrYdMTfcQVCeQNkTLYs=.44585470-c260-40b0-99da-90043771d95b@github.com>
References: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
 <ONP6px6r8myr0whjiH5OCJPTGrYdMTfcQVCeQNkTLYs=.44585470-c260-40b0-99da-90043771d95b@github.com>
Message-ID: <fxmZBykagTubTZAcHZh7KKgKA7n2pszksAC6I4R8NmM=.c7a9e416-8ea0-4fb2-a572-a6c3b15090b4@github.com>

On Fri, 26 Jul 2024 23:02:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which is a simple doc only change to java.text.DecimalFormat.
>> 
>> Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well.
>> 
>> A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove duplicate

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20361#pullrequestreview-2202861133

From duke at openjdk.org  Sat Jul 27 13:01:05 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 27 Jul 2024 13:01:05 GMT
Subject: <i18n dev> =?utf-8?b?UkZSOiA4MzM1NzkxOiBTcGVlZCDigIvigIt1cCBq?=
 =?utf-8?b?LnUuRm9ybWF0dGVyICYgU3RyaW5nLmZvcm1hdCBbdjVd?=
In-Reply-To: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
References: <MKjElzY83ptZtbn4Ej-U0VCoQJyO_6Q_fV2VwFX_P4U=.e82b0dfe-f49f-4c4b-9264-708016bfbf66@github.com>
Message-ID: <piH6QlpDTj8yu7qLfGNR4UpN9k7VgSliDFXj0TEVKeA=.03911d54-71c3-4337-81a9-60c565d5ff5b@github.com>

> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently.
> 
> 
> Improved performance includes the following:
> 
> ## 1. Write directly during the parse process to reduce object allocation.
> 
> In the current Formatter implementation, some objects do not need to be allocated, such as:
> 
> 
> class Formatter {
>     public Formatter format(Locale l, String format, Object ... args) {
>     	List<FormatString> fsa = parse(format);
>     	// ...
>     }
> 
>     static List<FormatString> parse(String s) {
>     	ArrayList<FormatString> al = new ArrayList<>();
> 
>         while (i < max) {
>             int n = s.indexOf('%', i);
>             if (n < 0) {
>                 // 
>                 al.add(new FixedString(s, i, max));
>             }
>         }
>     }
> }
> 
> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List<FormatString> fsa` to store it.
> 
> ## 2. Fast path print
> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method.
> 
> ## 3. String.format directly calls j.u.Formatter
> String.format directly calls j.u.Formatter via SharedSecrets to improve performance

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge remote-tracking branch 'upstream/master' into optim_str_format_202407
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
 - Implementing JavaUtilFormatterAccess using anonymous class
 - Merge remote-tracking branch 'upstream/master' into optim_str_format_202407
 - use unknownFormatConversion method construct UnknownFormatConversionException
 - uppercase static final field name & code format
 - add stable annotation
 - replace cast to pattern matching
 - speed up j.u.Formatter & String.format

-------------

Changes: https://git.openjdk.org/jdk/pull/20055/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=04
  Stats: 680 lines in 6 files changed: 554 ins; 60 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/20055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20055/head:pull/20055

PR: https://git.openjdk.org/jdk/pull/20055

From duke at openjdk.org  Sat Jul 27 13:04:23 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 27 Jul 2024 13:04:23 GMT
Subject: <i18n dev> RFR: 8335366: Improve String.format performance with
 fastpath [v14]
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <nyyKqtSwG2T4_5eye8S02JbHSRiKw71ewn8C-DMxo-g=.eb6fd82f-81d0-41db-8462-8597f667b1c0@github.com>

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

Shaojin Wen 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 19 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into optim_str_format_202407_fastpath
 - last specifier support %n
 - optimize width padding
 - improve StringFormat benchmark
 - add more test
 - add StringFormat test
 - code style
 - Update src/java.base/share/classes/java/lang/StringFormat.java
   
   Co-authored-by: David Schlosnagle <schlosna at gmail.com>
 - laze init for `decimal fast path locale`
 - isBigInt -> isLong
 - ... and 9 more: https://git.openjdk.org/jdk/compare/e840c78a...7313cdbd

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19956/files
  - new: https://git.openjdk.org/jdk/pull/19956/files/f1ae26a0..7313cdbd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=12-13

  Stats: 35144 lines in 1152 files changed: 21627 ins; 8503 del; 5014 mod
  Patch: https://git.openjdk.org/jdk/pull/19956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956

PR: https://git.openjdk.org/jdk/pull/19956

From duke at openjdk.org  Sat Jul 27 19:25:30 2024
From: duke at openjdk.org (Andriy Plokhotnyuk)
Date: Sat, 27 Jul 2024 19:25:30 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v2]
In-Reply-To: <OFz7ISGQy3izyS5XEFoe7uTrcfxj9JCo_FueS1YRnM4=.67fa807f-9cc1-4d70-81e8-c25692a12377@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <0rRenYTABuRAzJxLQ7llecvge7VUEUab5wU_M78_e5c=.88b3b0c7-f6e2-4dfa-bbf8-3820fdf43e5d@github.com>
 <ts5xu5DuSJOyEgJeMUO40eDyG1Aando4jibuDfE01DU=.3878fedb-3f0e-4b97-9f87-51f455ae74c7@github.com>
 <OFz7ISGQy3izyS5XEFoe7uTrcfxj9JCo_FueS1YRnM4=.67fa807f-9cc1-4d70-81e8-c25692a12377@github.com>
Message-ID: <Rjgb_UIEKT8PuzCnXI-xWNJd3oXvDgZ7Ezkfx0J0p5U=.3243533a-f1af-4614-8a9c-302fd6aff851@github.com>

On Fri, 26 Jul 2024 18:03:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > Could you please review [these](https://github.com/openjdk/jdk/pull/11986) proposed changes for instantiation of `Instant` values with already normalized nanos?
> 
> @plokhotnyuk Your contribution cannot be acted upon until the OCA is confirmed. If you have not submitted an OCA, please do so. See https://oca.opensource.oracle.com/

@RogerRiggs Thanks for your support!

I've submitted a signed OCA more than year ago and nobody answered me yet. 

Today's attempt shows the following notification:
![image](https://github.com/user-attachments/assets/2161d087-c7ab-4411-9cf6-4eba0bdcec29)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2254233234

From scolebourne at openjdk.org  Sun Jul 28 13:39:31 2024
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Sun, 28 Jul 2024 13:39:31 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v2]
In-Reply-To: <0rRenYTABuRAzJxLQ7llecvge7VUEUab5wU_M78_e5c=.88b3b0c7-f6e2-4dfa-bbf8-3820fdf43e5d@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <0rRenYTABuRAzJxLQ7llecvge7VUEUab5wU_M78_e5c=.88b3b0c7-f6e2-4dfa-bbf8-3820fdf43e5d@github.com>
Message-ID: <KeBDhChNAXO67eNZWVUSB5c2QKs4A4Z-C5zhV7iYAws=.0e7d13cb-ca46-4ec4-9708-c6c1722a6809@github.com>

On Fri, 26 Jul 2024 15:44:59 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comment

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3812:

> 3810:             int inNano = NANO_OF_SECOND.checkValidIntValue(inNanos != null ? inNanos : 0);
> 3811:             // use LocalDateTime.toString, If fractionalDigits < 0, printNano is implemented in LocalDateTime
> 3812:             LocalDateTime ldt = LocalDateTime.ofEpochSecond(inSecs, fractionalDigits >= 0 ? 0 : inNano, ZoneOffset.UTC);

I believe this whole approach is flawed. The comment above says:

`// use INSTANT_SECONDS, thus this code is not bound by Instant.MAX`

which indicates that the instant value may not fit in `LocalDateTime`.

You may be able to special case certain code paths to use `LocalDateTime`, but that makes things more complex, and not necessarily faster.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1694249198

From scolebourne at openjdk.org  Sun Jul 28 13:39:32 2024
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Sun, 28 Jul 2024 13:39:32 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v2]
In-Reply-To: <hZtN4RXWWLNKHNU6Qgq3z0vGcdEDC4gDWCn5fhzXWiY=.0639017a-a3e8-4abf-ae5c-08dc16e04bd5@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <nzFIZC5L68XSclC4G5-pTKxK3nTEdQTfdebZJWEQrzA=.dc5bfa47-5e9f-40fb-81cb-a4661e361f91@github.com>
 <hZtN4RXWWLNKHNU6Qgq3z0vGcdEDC4gDWCn5fhzXWiY=.0639017a-a3e8-4abf-ae5c-08dc16e04bd5@github.com>
Message-ID: <i8f5NZEJXvHTp8VG13hRp13jczddYs5OQwJsFOodcFM=.57fc843e-bd6e-450c-8a78-b224b156f049@github.com>

On Fri, 26 Jul 2024 15:32:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3818:
>> 
>>> 3816:             }
>>> 3817:             // add fraction
>>> 3818:             if (fractionalDigits > 0) {
>> 
>> This breaks the logic. `fractionalDigits` can be negative in the block below
>
> If fractionalDigits < 0, printNano is implemented in LocalDateTime

`fractionalDigits == -2` is used to output 0, 3, 6 or 9 fractional digits as needed. This can be handled by `LocalDateTime`.

`fractionalDigits == -1`  is used to output as many fractional digits as needed, from 0 to 9 digits. This is NOT handled by `LocalDateTime`.

Furthermore, if the `-2` branch is handled by `LocalDateTime` then the logic below for `-2` is redundant.

If the tests did not fail as a result of this change, then I imagine the tests need improving.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1694248869

From duke at openjdk.org  Sun Jul 28 15:52:03 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 28 Jul 2024 15:52:03 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v3]
In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
Message-ID: <TqSGxLtidk6LhthFo2Yz1qoHLrN_3wZCeKvXOKZJew8=.b37a8e79-cc7f-4695-9b08-560b5a2be6a9@github.com>

> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  1. fix handle fraction == -1
  2. Split two methods to make codeSize less than 325

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20353/files
  - new: https://git.openjdk.org/jdk/pull/20353/files/64403d5f..75798425

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=01-02

  Stats: 200 lines in 2 files changed: 194 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20353.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20353/head:pull/20353

PR: https://git.openjdk.org/jdk/pull/20353

From duke at openjdk.org  Sun Jul 28 17:09:31 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 28 Jul 2024 17:09:31 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v3]
In-Reply-To: <TqSGxLtidk6LhthFo2Yz1qoHLrN_3wZCeKvXOKZJew8=.b37a8e79-cc7f-4695-9b08-560b5a2be6a9@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <TqSGxLtidk6LhthFo2Yz1qoHLrN_3wZCeKvXOKZJew8=.b37a8e79-cc7f-4695-9b08-560b5a2be6a9@github.com>
Message-ID: <Sx2Xh-fWeNvV7PqIhaspRuK8nRCxwcLjG6GRmBp4y6Y=.8cf292fb-9c1b-4f6c-9ae6-42a56930639f@github.com>

On Sun, 28 Jul 2024 15:52:03 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. fix handle fraction == -1
>   2. Split two methods to make codeSize less than 325

@jodastephen thank you for your patience in answering my questions. 

Now I've used a new way to implement it, splitting it into two sub-methods without changing the original logic, which also makes codeSize < 325, and the performance is also faster than before. Here are the performance numbers running on a MacBook M1 Pro:


- # master 5ff7c57f9ff5428ef3d2aedd7e860bb1e8ff29ea
-Benchmark                       Mode  Cnt  Score   Error   Units
-ToStringBench.instantToString  thrpt   15  4.558 ? 0.561  ops/ms

+ # current 757984258257fd82c389f3ee7bd9be927375e2e0
+Benchmark                       Mode  Cnt  Score   Error   Units
+ToStringBench.instantToString  thrpt   15  5.564 ? 0.465  ops/ms +22.07%


I also added relevant tests to prevent errors from being discovered in future related changes.

I hope to reuse LocalDateTime.toString for the most common paths, so that we can also use LocalDateTime.formatTo method, which can reduce object allocation.

I plan to continue to optimize the formatTo method of LocalTime and LocalDate, so that InstantPrinterParser.format can also benefit from it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2254582635

From jlu at openjdk.org  Mon Jul 29 19:30:36 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 29 Jul 2024 19:30:36 GMT
Subject: <i18n dev> Integrated: 8337285: Examine java.text.DecimalFormat API
 for api/implXxx tag usage
In-Reply-To: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
References: <e5bno-Ex7Jo60A7CgS8bMbcp5Ycw2F_zmkBFJ7A-qhg=.f3d98152-6bae-4751-b7d6-88c7b7e2c1c1@github.com>
Message-ID: <DnDYFj0S5btt5bCjkQsT2nztVOW1CoOVhKCeVYr-Ib4=.b4504c2e-8939-435e-8759-457b905c3327@github.com>

On Fri, 26 Jul 2024 19:17:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a simple doc only change to java.text.DecimalFormat.
> 
> Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well.
> 
> A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted.

This pull request has now been integrated.

Changeset: bd36b6ae
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd36b6ae5d0d760670a0bd722878614a6cd553d6
Stats:     43 lines in 1 file changed: 13 ins; 16 del; 14 mod

8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage

Reviewed-by: naoto, liach

-------------

PR: https://git.openjdk.org/jdk/pull/20361