On Tue, 10 Oct 2023 13:47:07 GMT, Roger Riggs wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add test cases, make set sizing more explicit
>
> test/jdk/java/util/BitSet/Immutabl
On Mon, 9 Oct 2023 03:29:38 GMT, Chen Liang wrote:
>> Alternative to #16082
>>
>> Name (unchanged) Cnt Base Error Test
>> Error Unit Change
>> URLEncodeDecode.testEncodeLatin1 0 15 2,066 ± 0,104 1,899 ±
>> 0,007 ms/op 1,09x (p = 0,000*)
>>
Alternative to #16082
Name (unchanged) Cnt Base Error Test Error
Unit Change
URLEncodeDecode.testEncodeLatin1 0 15 2,066 ± 0,104 1,899 ± 0,007
ms/op 1,09x (p = 0,000*)
URLEncodeDecode.testEncodeLatin1 75 15 0,934 ± 0,017 0,811 ±
On Mon, 9 Oct 2023 20:40:43 GMT, 温绍锦 wrote:
>> @cl4es made performance optimizations for the simple specifiers of
>> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
>> same idea, I continued to make improvements. I made patterns like %2d %02d
>> also be optimized.
On Tue, 3 Oct 2023 21:37:46 GMT, 温绍锦 wrote:
> j.u.Formatter now prints "%tF" (iso standard date) and the result is
> incorrect when processing year < 0 or year >
I think this deserves a discussion on the mailing list before jumping to a PR,
as neither `%tF` nor the ISO-8601 standard it
On Fri, 29 Sep 2023 20:03:09 GMT, 温绍锦 wrote:
>> In the improvement of @cl4es PR #15591, the advantages of non-lookup-table
>> were discussed.
>>
>> But if the input is byte[], using lookup table can improve performance.
>>
>> For HexFormat#formatHex(Appendable, byte[]) and
On Thu, 5 Oct 2023 10:31:31 GMT, Raffaello Giulietti
wrote:
>> See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the
>> details.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Avoid localized
digestString.append(
Integer.toHexString(digest[i] & 0x00ff));
}
}
return digestString.toString();
}
}
```
- wenshao
------
发件人：Mark Reinhold
发送时间：2023年10月2日(星期一)
I think this goes against the grain: StringBuilder is a simple builder for
non-localized unformatted output. For formatted output there’s Formatter,
String.format and, with JEP 430[1], FMT.”…” to help output string data in more
advanced, formatted and localized ways. The latter has
On Sun, 24 Sep 2023 20:27:53 GMT, 温绍锦 wrote:
>> @cl4es made performance optimizations for the simple specifiers of
>> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
>> same idea, I continued to make improvements. I made patterns like %2d %02d
>> also be optimized.
On Mon, 25 Sep 2023 12:06:52 GMT, 温绍锦 wrote:
>> @cl4es made performance optimizations for the simple specifiers of
>> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
>> same idea, I continued to make improvements. I made patterns like %2d %02d
>> also be optimized.
On Mon, 25 Sep 2023 11:36:10 GMT, 温绍锦 wrote:
> The reason why I split it into multiple small methods is to avoid a single
> method codeSize > 325. After merging small methods, the performance will
> decrease.
Yes, I can refactor to keep the same structure and verify performance is
neutral or
On Sun, 24 Sep 2023 20:27:53 GMT, 温绍锦 wrote:
>> @cl4es made performance optimizations for the simple specifiers of
>> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
>> same idea, I continued to make improvements. I made patterns like %2d %02d
>> also be optimized.
On Sun, 24 Sep 2023 13:08:58 GMT, 温绍锦 wrote:
>> @cl4es made performance optimizations for the simple specifiers of
>> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
>> same idea, I continued to make improvements. I made patterns like %2d %02d
>> also be optimized.
On Sun, 24 Sep 2023 11:59:51 GMT, 温绍锦 wrote:
>> @cl4es made performance optimizations for the simple specifiers of
>> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
>> same idea, I continued to make improvements. I made patterns like %2d %02d
>> also be optimized.
On Sun, 17 Sep 2023 16:01:33 GMT, 温绍锦 wrote:
> @cl4es made performance optimizations for the simple specifiers of
> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
> same idea, I continued to make improvements. I made patterns like %2d %02d
> also be optimized.
>
>
On Mon, 18 Sep 2023 02:59:06 GMT, 温绍锦 wrote:
>> The change code of print fast-path has been deleted, and parse fast-path has
>> added support for the pattern "%8.3f".
>>
>> Where to draw the line of parse fast-path? I have seen patterns that cause
>> performance problems, and they can be
On Sun, 17 Sep 2023 16:01:33 GMT, 温绍锦 wrote:
> @cl4es made performance optimizations for the simple specifiers of
> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
> same idea, I continued to make improvements. I made patterns like %2d %02d
> also be optimized.
>
>
On Wed, 20 Sep 2023 09:12:48 GMT, Claes Redestad wrote:
> This patch reverts the use of `ByteArrayLittleEndian` in `StringLatin1`.
>
> This use is the cause of a small (~1.5ms) startup regression in 22-b15. While
> a manageable startup regression in and of itself, the use of
On Thu, 21 Sep 2023 13:55:18 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>> line 236:
>>
>>> 234: private void inflate() {
>>> 235: int singleBytes = JLA.countPositives(rawBytes, offset,
>>> rawLen);
>>> 236:
On Thu, 21 Sep 2023 02:38:08 GMT, Chen Liang wrote:
>> Like #12077, this uses JDK's internal utilities to speed up ASCII reading in
>> Class files, where most identifiers, from conventions to attribute names,
>> are ASCII. See the JBS issue for more in-depth explanations.
>>
>> Before:
On Thu, 21 Sep 2023 02:38:08 GMT, Chen Liang wrote:
>> Like #12077, this uses JDK's internal utilities to speed up ASCII reading in
>> Class files, where most identifiers, from conventions to attribute names,
>> are ASCII. See the JBS issue for more in-depth explanations.
>>
>> Before:
On Wed, 20 Sep 2023 09:21:00 GMT, Chen Liang wrote:
> Can #14636 be a solution to avoid early VH initialization?
I think #14636 would more or less solve the startup regression, yes, but the
jury is out on whether we want to accept that. There's value in taking steps to
make `VH`
On Wed, 20 Sep 2023 09:12:48 GMT, Claes Redestad wrote:
> This patch reverts the use of `ByteArrayLittleEndian` in `StringLatin1`.
>
> This use is the cause of a small (~1.5ms) startup regression in 22-b15. While
> a manageable startup regression in and of itself, the use of
On Wed, 20 Sep 2023 09:12:48 GMT, Claes Redestad wrote:
> This patch reverts the use of `ByteArrayLittleEndian` in `StringLatin1`.
>
> This use is the cause of a small (~1.5ms) startup regression in 22-b15. While
> a manageable startup regression in and of itself, the use of
This patch reverts the use of `ByteArrayLittleEndian` in `StringLatin1`.
This use is the cause of a small (~1.5ms) startup regression in 22-b15. While a
manageable startup regression in and of itself, the use of `VarHandles` in core
utility classes brings an increased risk of bootstrap
On Tue, 19 Sep 2023 09:25:36 GMT, Chen Liang wrote:
>> 温绍锦 has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> "-" -> "& ~"
>
> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 103:
>
>> 101: short v = DIGITS[i &
On Thu, 7 Sep 2023 11:13:44 GMT, Per Minborg wrote:
> This PR outlines a solution for making immutable maps `@ValueBased` by
> removing cacheing of certain values in `AbstractMap`.
>
> By removing these caching fields in `AbstractMap`, we can make the immutable
> maps `@ValueBased` and at the
On Mon, 18 Sep 2023 13:51:06 GMT, Chen Liang wrote:
>> In the improvement of @cl4es PR #15591, the advantages of non-lookup-table
>> were discussed.
>>
>> But if the input is byte[], using lookup table can improve performance.
>>
>> For HexFormat#formatHex(Appendable, byte[]) and
On Fri, 15 Sep 2023 19:11:48 GMT, 温绍锦 wrote:
> The byte[] length used by HexFormatBench is 512. In this scenario, the
> performance improvement of using table lookup is significant.
Is this a common use-case? I could see an argument that formatting small chunks
is much more common, where
On Fri, 15 Sep 2023 18:04:29 GMT, 温绍锦 wrote:
> In the improvement of @cl4es PR #15591, the advantages of non-lookup-table
> were discussed.
>
> But if the input is byte[], using lookup table can improve performance.
>
> For HexFormat#formatHex(Appendable, byte[]) and
On Mon, 18 Sep 2023 15:00:20 GMT, 温绍锦 wrote:
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>>
>>
>>
>> ## 1.
>>
On Mon, 18 Sep 2023 04:11:25 GMT, 温绍锦 wrote:
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>>
>>
>>
>> ## 1.
>>
On Mon, 18 Sep 2023 03:00:25 GMT, Chen Liang wrote:
>> 温绍锦 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 ten additional commits since the
>>
On Thu, 14 Sep 2023 13:44:59 GMT, Roger Riggs wrote:
>> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 277:
>>
>>> 275: }
>>> 276:
>>> 277: public static String toHexString(long value) {
>>
>> We intend to use this utility method in coming PRs.
>
> The String concat
On Wed, 6 Sep 2023 13:36:22 GMT, Claes Redestad wrote:
> This PR seeks to improve formatting of hex digits using `java.util.HexFormat`
> somewhat.
>
> This is achieved getting rid of a couple of lookup tables, caching the result
> of `HexFormat.of().withUpperCase()`, an
On Fri, 8 Sep 2023 10:32:40 GMT, Claes Redestad wrote:
>> This PR seeks to improve formatting of hex digits using
>> `java.util.HexFormat` somewhat.
>>
>> This is achieved getting rid of a couple of lookup tables, caching the
>> result of `HexFormat.of().withU
On Tue, 12 Sep 2023 22:44:35 GMT, 温绍锦 wrote:
>> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 112:
>>
>>> 110: | (DIGITS[b1 & 0xff] << 16)
>>> 111: | (((long) DIGITS[b2 & 0xff]) << 32)
>>> 112: | (((long) DIGITS[b3 & 0xff]) <<
On Tue, 12 Sep 2023 13:10:42 GMT, 温绍锦 wrote:
>> Of course, the optimization of DateTimeFormatter is more general, and we can
>> spend time doing it later. The format of toString is fixed, we can not use
>> DateTimeFormatter.
>
>> Have you considered potentially more generalizable optimizations
On Tue, 12 Sep 2023 17:23:00 GMT, 温绍锦 wrote:
>> improve date toString performance, includes:
>>
>> java.util.Date.toString
>> java.util.Date.toGMTString
>> java.time.Instant.toString
>> java.time.LocalDate.toString
>> java.time.LocalDateTime.toString
>> java.time.LocalTime.toString
>
> 温绍锦 has
On Mon, 11 Sep 2023 16:13:01 GMT, 温绍锦 wrote:
>> It was a suggestion, implicitly paired with removing ` + (year < 0 ? 1 : 0)`
>> from line 2188.
>
> The reason for not using off++ is that it can be executed out of order, which
> may result in better performance.
I don't think that would
On Tue, 12 Sep 2023 13:27:29 GMT, 温绍锦 wrote:
>> java.util.DecimalDigits::DIGITS and java.lang.StringLatin1.PACKED_DIGITS are
>> duplicates, We need to move
>> java.util.Digits/OctalDigits/DecimalDigits/HexDigits to the
>> jdk.internal.util package, and modify these classes to public class, so
On Tue, 12 Sep 2023 13:24:56 GMT, 温绍锦 wrote:
> I prefer to use little endian, most environments are little endian. Changes
> to HexDigit will have to wait until #PR 14745 is merged.
I don't have a very strong opinion except that we should be consistent across
these related implementations. If
On Tue, 12 Sep 2023 10:11:53 GMT, Claes Redestad wrote:
> If there's no significant performance difference I would prefer if we kept
> `DecimalDigits::DIGITS` big-endian encoded - which is more intuitive to most
> - and adjust code depending on `DecimalDigits::digitPair` to use `
On Tue, 12 Sep 2023 01:00:39 GMT, 温绍锦 wrote:
>> Some codes in core libs are duplicated, including:
>> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
>> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>>
>> We can reduce duplication through JavaLangAccess,
On Mon, 11 Sep 2023 18:58:56 GMT, Roger Riggs wrote:
>> 温绍锦 has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> revert code format
>
> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 1:
>
>> 1: /*
>
> Can git be
On Mon, 11 Sep 2023 15:57:22 GMT, 温绍锦 wrote:
>> Some codes in core libs are duplicated, including:
>> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
>> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>>
>> We can reduce duplication through JavaLangAccess,
On Mon, 11 Sep 2023 14:38:28 GMT, 温绍锦 wrote:
>> src/java.base/share/classes/java/time/LocalDate.java line 2181:
>>
>>> 2179: if (yearAbs < 1000) {
>>> 2180: if (year < 0) {
>>> 2181: buf[off] = '-';
>>
>> `buf[off++] = '-';`
>
> this place doesn't need off++
On Mon, 11 Sep 2023 13:53:19 GMT, Martin Doerr wrote:
> Shouldn't this get optimized by the JIT compilers? Why is
> `ByteArrayLittleEndian` supposed to be faster? Note that there are still
> several Big Endian platforms: AIX, s390x and old linux ppc64 (still kept
> alive)
And none of these
On Mon, 11 Sep 2023 12:12:17 GMT, 温绍锦 wrote:
> improve date toString performance, includes:
>
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString
As @liach says this
On Mon, 11 Sep 2023 12:50:43 GMT, Martin Doerr wrote:
> Your earlier version didn't work. The one which I have successfully tested is
> after 2nd commit.
I think this looks OK.
This patch probably reverts performance numbers on little-endian on some
measures to pre-JDK-8310929 levels. A
On Mon, 11 Sep 2023 08:49:18 GMT, Andrey Turbanov wrote:
>> 温绍锦 has updated the pull request incrementally with two additional commits
>> since the last revision:
>>
>> - remove duplicate stringSize
>> - update related comments
>
>
On Sun, 10 Sep 2023 16:39:30 GMT, 温绍锦 wrote:
> https://bugs.openjdk.org/browse/JDK-8310929
>
> @TheRealMDoerr Feedback:
>
>
> We're getting test failures on AIX:
> compiler/intrinsics/Test8215792.java
> compiler/intrinsics/string/TestStringIntrinsics.java
>
On Sun, 10 Sep 2023 18:08:44 GMT, Roger Riggs wrote:
>> 温绍锦 has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> move java.util.DecimalDigits to jdk.internal.util.DecimalDigits
>
> src/java.base/share/classes/java/util/Digits.java line 36:
>
On Sun, 10 Sep 2023 16:39:30 GMT, 温绍锦 wrote:
> https://bugs.openjdk.org/browse/JDK-8310929
>
> @TheRealMDoerr Feedback:
>
>
> We're getting test failures on AIX:
> compiler/intrinsics/Test8215792.java
> compiler/intrinsics/string/TestStringIntrinsics.java
>
On Sun, 10 Sep 2023 16:15:01 GMT, 温绍锦 wrote:
> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>
> We can reduce duplication through JavaLangAccess, which is
On Sat, 9 Sep 2023 07:59:30 GMT, 温绍锦 wrote:
>> Perhaps you could extract the `digitPair` method you're adding in #1 to
>> a separate PR and use that to remove `HexDigits::DIGITS`?
>
> Please help me create an issue, and I will submit a new PR to modify it.
Filed
On Sat, 9 Sep 2023 07:08:07 GMT, Claes Redestad wrote:
>> 温绍锦 has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> lo | hi => hi | lo
>
> src/java.base/share/classes/java/util/HexDigits.java line 42:
>
On Fri, 8 Sep 2023 20:36:31 GMT, 温绍锦 wrote:
>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved
>> discussions, continue to make improvements.
>>
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make
On Fri, 8 Sep 2023 23:49:04 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/util/HexDigits.java line 66:
>>
>>> 64: */
>>> 65: @Stable
>>> 66: private static final short[] DIGITS;
>>
>> Maybe it should be `char[]` instead since it’s encoded using unsigned 16‑bit
>>
On Fri, 8 Sep 2023 15:41:41 GMT, Claes Redestad wrote:
>> Notice there is patch https://github.com/openjdk/jdk/pull/14655 (bug
>> 8310901) for converting these usages to a new `newStringLatin1NoRepl`.
>
> Going from `jla.newStringNoRepl(bytes, ISO_...)` to
> `jla.newStr
On Fri, 8 Sep 2023 15:39:47 GMT, Chen Liang wrote:
>> newStringLatin1NoRepl does not significantly help performance, but it
>> simplifies the code.
>>
>> Of course, there is another advantage: because the call will be simpler,
>> making it easier for the caller method to implement codeSize
On Fri, 8 Sep 2023 12:00:17 GMT, 温绍锦 wrote:
>> BigDecimal is a commonly used class in business development, It is often
>> necessary to perform toString or toPlainString operations on BigDecimal.
>>
>> The current version uses StringBuilder resulting in multiple memory
>> allocations, I made
On Wed, 6 Sep 2023 13:36:22 GMT, Claes Redestad wrote:
> This PR seeks to improve formatting of hex digits using `java.util.HexFormat`
> somewhat.
>
> This is achieved getting rid of a couple of lookup tables, caching the result
> of `HexFormat.of().withUpperCase()`, an
exLower 15 0,198 ± 0,001 0,119 ± 0,008 us/op
> 40,1% (p = 0,000*)
> :gc.alloc.rate15 0,007 ± 0,000 0,007 ± 0,000 MB/sec
> -0,0% (p = 0,816 )
> :gc.alloc.rate.norm 15 0,001 ± 0,000 0,001 ± 0,000 B/op
> -40,1% (p = 0
On Fri, 8 Sep 2023 08:47:04 GMT, Raffaello Giulietti
wrote:
>> This PR seeks to improve formatting of hex digits using
>> `java.util.HexFormat` somewhat.
>>
>> This is achieved getting rid of a couple of lookup tables, caching the
>> result of `HexFormat.of().withUpperCase()`, and removing
On Wed, 6 Sep 2023 13:36:22 GMT, Claes Redestad wrote:
> This PR seeks to improve formatting of hex digits using `java.util.HexFormat`
> somewhat.
>
> This is achieved getting rid of a couple of lookup tables, caching the result
> of `HexFormat.of().withUpperCase()`, an
On Wed, 6 Sep 2023 22:22:12 GMT, 温绍锦 wrote:
>> Optimization for:
>> Integer.toString
>> Long.toString
>> StringBuilder#append(int)
>>
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test
On Wed, 6 Sep 2023 16:10:23 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/util/HexFormat.java line 644:
>>
>>> 642: return (char)('a' - 10 + value);
>>> 643: }
>>> 644: return (char)('A' - 10 + value);
>>
On Tue, 5 Sep 2023 00:10:12 GMT, 温绍锦 wrote:
>> Optimization for:
>> Integer.toString
>> Long.toString
>> StringBuilder#append(int)
>>
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test
On Wed, 6 Sep 2023 15:29:45 GMT, Raffaello Giulietti
wrote:
>> This PR seeks to improve formatting of hex digits using
>> `java.util.HexFormat` somewhat.
>>
>> This is achieved getting rid of a couple of lookup tables, caching the
>> result of `HexFormat.of().withUpperCase()`, and removing
On Wed, 6 Sep 2023 15:34:54 GMT, Roger Riggs wrote:
>> This PR seeks to improve formatting of hex digits using
>> `java.util.HexFormat` somewhat.
>>
>> This is achieved getting rid of a couple of lookup tables, caching the
>> result of `HexFormat.of().withUpperCase()`, and removing tiny
On Tue, 5 Sep 2023 00:10:12 GMT, 温绍锦 wrote:
>> Optimization for:
>> Integer.toString
>> Long.toString
>> StringBuilder#append(int)
>>
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test
This PR seeks to improve formatting of hex digits using `java.util.HexFormat`
somewhat.
This is achieved getting rid of a couple of lookup tables, caching the result
of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens
in the `formatHex(A, byte)` method. Improvements
On Tue, 5 Sep 2023 15:46:17 GMT, 温绍锦 wrote:
>> BigDecimal is a commonly used class in business development, It is often
>> necessary to perform toString or toPlainString operations on BigDecimal.
>>
>> The current version uses StringBuilder resulting in multiple memory
>> allocations, I made
On Mon, 4 Sep 2023 16:00:05 GMT, 温绍锦 wrote:
>> Optimization for:
>> Integer.toString
>> Long.toString
>> StringBuilder#append(int)
>>
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test
On Mon, 4 Sep 2023 15:50:12 GMT, 温绍锦 wrote:
>> Optimization for:
>> Integer.toString
>> Long.toString
>> StringBuilder#append(int)
>>
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test
On Fri, 1 Sep 2023 18:40:55 GMT, 温绍锦 wrote:
>> Optimization for:
>> Integer.toString
>> Long.toString
>> StringBuilder#append(int)
>>
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test
On Mon, 4 Sep 2023 06:54:40 GMT, Per Minborg wrote:
>> This PR proposes adding a new method to BitSet that provides an immutable
>> snapshot of the set in the form of an `IntPredicate`.
>>
>> The predicate is eligible for constant folding.
>>
>> Here are some classes in the JDK that would
On Sun, 3 Sep 2023 17:36:03 GMT, 温绍锦 wrote:
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>>
>>
>>
>> ## 1.
>>
On Sun, 3 Sep 2023 17:36:03 GMT, 温绍锦 wrote:
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>>
>>
>>
>> ## 1.
>>
On Fri, 1 Sep 2023 18:44:13 GMT, 温绍锦 wrote:
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>>
>>
>>
>> ## 1.
>>
On Fri, 1 Sep 2023 08:21:13 GMT, Per Minborg wrote:
> This PR proposes adding a new method to BitSet that provides an immutable
> snapshot of the set in the form of an `IntPredicate`.
>
> The predicate is eligible for constant folding.
>
> Here are some classes in the JDK that would benefit
On Tue, 18 Jul 2023 01:49:17 GMT, 温绍锦 wrote:
>> Optimization for:
>> Integer.toString
>> Long.toString
>> StringBuilder#append(int)
>>
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test
On Thu, 6 Jul 2023 05:20:14 GMT, 温绍锦 wrote:
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>>
>>
>>
>> ## 1.
>>
On Thu, 10 Aug 2023 11:38:08 GMT, Pavel Rappo wrote:
>> Pavel Rappo has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 13 additional
>> commits
On Wed, 9 Aug 2023 22:54:28 GMT, Pavel Rappo wrote:
>> Please review this PR to use modern APIs and language features to simplify
>> equals, hashCode, and compareTo for BigInteger. If you have any performance
>> concerns, please raise them.
>>
>> This PR is cherry-picked from a bigger,
On Thu, 10 Aug 2023 11:40:52 GMT, Pavel Rappo wrote:
>> My bad. Forget my note
>
>> Some have a preference for providing a seed for `Random` instances in
>> micros. Either hard-coded or through a `@Param` (I find this a bit
>> excessive). Doing so might reduce run-to-run noise.
>
> I hear
On Wed, 9 Aug 2023 22:54:28 GMT, Pavel Rappo wrote:
>> Please review this PR to use modern APIs and language features to simplify
>> equals, hashCode, and compareTo for BigInteger. If you have any performance
>> concerns, please raise them.
>>
>> This PR is cherry-picked from a bigger,
On Wed, 9 Aug 2023 14:41:51 GMT, Jim Laskey wrote:
> 8313809: String template fails with java.lang.StringIndexOutOfBoundsException
> if last fragment is UTF16
Marked as reviewed by redestad (Reviewer).
-
PR Review:
On Tue, 8 Aug 2023 19:34:05 GMT, Jim Laskey wrote:
>> The last fragment of a string template does not get it's coder added to the
>> mix.
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Requested by @cl4es
This works.
On Tue, 8 Aug 2023 18:31:04 GMT, Jim Laskey wrote:
> The last fragment of a string template does not get it's coder added to the
> mix.
LGTM. This also adds an implicit null check on the last fragment.
src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1129:
> 1127:
On Thu, 13 Jul 2023 17:57:16 GMT, Andrey Turbanov wrote:
> Couple of static fields in Math could be declared `final`.
Looks good and trivial.
-
Marked as reviewed by redestad (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/14875#pullrequestreview-1565168404
On Fri, 28 Jul 2023 10:49:34 GMT, Pavel Rappo wrote:
> Perhaps surprisingly, we don't need int[]; what JDK seems to use is these:
>
> * byte[]
> * unsigned byte[]
> * Object[]
All `vectorizedHashCode` variants are exposed (and testable) via the public
On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo wrote:
> This PR adds an internal method to calculate hash code from the provided
> integer array, offset and length into that array, and the initial hash code
> value.
>
> Current options for calculating a hash code for int[] are inflexible. It's
On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo wrote:
> This PR adds an internal method to calculate hash code from the provided
> integer array, offset and length into that array, and the initial hash code
> value.
>
> Current options for calculating a hash code for int[] are inflexible. It's
On Thu, 8 Jun 2023 16:15:21 GMT, Brett Okken wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove pointless comments
>
> src/java.base/share/classes/java/util/Arrays.java line 384
On Thu, 8 Jun 2023 15:08:28 GMT, Claes Redestad wrote:
> https://bugs.openjdk.org/browse/JDK-8301958 and later changes improved
> Arrays.copyOf/-Range methods to improve peak performance in microbenchmarks
> when copying the entire array, but it's resulted in a few lurking
tly more JIT activity. As a
> partial remedy I propose simplifying the implementation so that no new
> methods are added compared to the JDK 20 baseline. This patch maintains the
> microbenchmark speed-up from JDK-8301958 while reducing JIT compilations in
> startup/footprint benchma
On Thu, 8 Jun 2023 15:24:00 GMT, Jim Laskey wrote:
>> https://bugs.openjdk.org/browse/JDK-8301958 and later changes improved
>> Arrays.copyOf/-Range methods to improve peak performance in microbenchmarks
>> when copying the entire array, but it's resulted in a few lurking footprint
>>
401 - 500 of 742 matches
Mail list logo
