On Thu, 17 Jul 2025 10:27:27 GMT, Raffaello Giulietti
wrote:
>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 815:
>
>> 813: */
>> 814:
>> 815: private static final int init_jk[] = {2, 3, 4,
On Wed, 16 Jul 2025 04:53:04 GMT, Joe Darcy wrote:
> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
src/java.base/share/classes/java/lang/FdLibm.java line 457:
> 455: pio4 = 0x1.921fb54442d18p-1, // 7.85398163397448278999e-01
> 456: pio4lo=
On Sun, 15 Jun 2025 05:53:26 GMT, Shaojin Wen wrote:
>> In PR #22928, UUID introduced long-based vectorized hexadecimal to string
>> conversion, which can also be used in Integer::toHexString and
>> Long::toHexString to eliminate table lookups. The benefit of eliminating
&
On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote:
>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>>
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder
>> has a ByteBuffer. There are two layers of cache here, or the BufferedW
On Tue, 1 Jul 2025 02:33:16 GMT, Chen Liang wrote:
> I think we can split this into two parts:
>
> 1. Update buffering strategy for BufferedWriter when backing writer is an
> OutputStreamWriter
> 2. Use an alternative StreamDecoder impl if the CharsetDecoder is an
> ArrayDecoder
>
> This shou
On Tue, 1 Jul 2025 00:41:03 GMT, Xueming Shen wrote:
> While I understand the motivation behind the PR, it's a bit challenging, as a
> reviewer :-) to review a change that is essentially to 'break' the
> abstraction layer by surfacing a lower-level implementation to the top API
> solely for pe
On Tue, 1 Jul 2025 02:07:07 GMT, Brett Okken wrote:
> > StreamEncoder has a ByteBuffer that acts as a buffer,
>
> At a fixed sized of 512 bytes which cannot be affected by size passed into
> the BufferedWriter?
So I added this method StreamEncoder::growByteBufferIfEmptyNeeded and called it
in
On Mon, 30 Jun 2025 23:57:45 GMT, Brett Okken wrote:
> What about a benchmark which exercises the actual benefits of buffering? So
> many very small writes to a backing OutputStream which is (artificially)
> slow. Perhaps have an OutputStream which sleeps 1ms on every call. The write
> out mor
tly. In
> addition, improve write(String) in StreamEncoder to avoid unnecessary
> encoding conversion.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
Revert "BufferedWriter buffer use StringBuilder"
tly. In
> addition, improve write(String) in StreamEncoder to avoid unnecessary
> encoding conversion.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
BufferedWriter buffer use StringBuilder
-
Changes:
- all: h
tly. In
> addition, improve write(String) in StreamEncoder to avoid unnecessary
> encoding conversion.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
bug fix for encodeUTF8 & remove unused computeSizeUTF8
-
C
tly. In
> addition, improve write(String) in StreamEncoder to avoid unnecessary
> encoding conversion.
Shaojin Wen has updated the pull request incrementally with three additional
commits since the last revision:
- bug fix for encodeUTF8
- bug fix for encodeUTF8
- bug fix for
tly. In
> addition, improve write(String) in StreamEncoder to avoid unnecessary
> encoding conversion.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
copyright
-
Changes:
- all: https://git.openjdk.org/jdk/pu
On Fri, 27 Jun 2025 16:48:40 GMT, Shaojin Wen wrote:
> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>
> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has
> a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer
>
BufferedWriter -> OutputStreamWriter -> StreamEncoder
In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a
ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can
be removed. And when charset is UTF8, if the content of write(String) is
LATIN1,
On Wed, 29 Jan 2025 16:36:24 GMT, Shaojin Wen wrote:
> The byte[] allocated in Integer/Long.toString is fully filled, so we can use
> StringConcatHelper::newArray to create byte[] to improve performance.
This pull request has been closed without being integrated.
-
PR:
On Fri, 27 Jun 2025 19:09:27 GMT, Roger Riggs wrote:
>> Shaojin Wen has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 11 commits:
>>
>> - Merge remote-tracking branch 'upstream/master'
On Sun, 18 May 2025 12:48:07 GMT, Shaojin Wen wrote:
> Through JVM Option +PrintInlining, we found that String has a constructor
> codeSize of 852, which is too large. This caused failed to inline.
>
> The following is the output information of PrintInlining:
>
>
On Wed, 25 Jun 2025 00:13:56 GMT, Shaojin Wen wrote:
>> Through JVM Option +PrintInlining, we found that String has a constructor
>> codeSize of 852, which is too large. This caused failed to inline.
>>
>> The following is the output information of PrintInlining:
&g
erRiggs completed the optimization when the encoder is LATIN1 in PR
> #24967. This PR continues to complete the optimization when the encoder is
> UTF16.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
Update src/java.base/share/classes
On Mon, 26 May 2025 19:20:06 GMT, Shaojin Wen wrote:
>> Through JVM Option +PrintInlining, we found that String has a constructor
>> codeSize of 852, which is too large. This caused failed to inline.
>>
>> The following is the output information of PrintInlining:
&g
erRiggs completed the optimization when the encoder is LATIN1 in PR
> #24967. This PR continues to complete the optimization when the encoder is
> UTF16.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
Microbenchmark java.lang.StringBui
erRiggs completed the optimization when the encoder is LATIN1 in PR
> #24967. This PR continues to complete the optimization when the encoder is
> UTF16.
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 12 commits:
- inlin
g
> constructor
>
>
> String(Charset charset, byte[] bytes, int offset, int length) {}
>
> The above String constructor is too large; break it down into smaller methods
> with a codeSize under 325 to allow them to be inlined by the C2.
Shaojin Wen has updated the pull requ
On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter wrote:
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
>
On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter wrote:
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
>
On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter wrote:
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
>
misses occur.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
Update src/java.base/share/classes/java/util/UUID.java
Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
-
Changes:
- all: https://g
GITS cache array, which avoids
> performance degradation caused by cache misses.
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 41 commits:
- Merge remote-tracking branch 'origin/optim_parse_int_long_202501'
On Tue, 7 Jan 2025 10:39:18 GMT, Shaojin Wen wrote:
> In PR #22928, UUID introduced long-based vectorized hexadecimal to string
> conversion, which can also be used in Integer::toHexString and
> Long::toHexString to eliminate table lookups. The benefit of eliminating
> table loo
In PR #22928, UUID introduced long-based vectorized hexadecimal to string
conversion, which can also be used in Integer::toHexString and
Long::toHexString to eliminate table lookups. The benefit of eliminating table
lookups is that the performance is better when cache misses occur.
On Tue, 7 Jan 2025 10:39:18 GMT, Shaojin Wen wrote:
> In PR #22928, UUID introduced long-based vectorized hexadecimal to string
> conversion, which can also be used in Integer::toHexString and
> Long::toHexString to eliminate table lookups. The benefit of eliminating
> table loo
On Fri, 2 May 2025 03:53:23 GMT, Shaojin Wen wrote:
>> This is an optimization for decimal Integer.parseInt and Long.parseLong,
>> which improves performance by about 10%. The optimization includes:
>> 1. Improve performance by parsing 2 numbers at a time, which has performanc
On Wed, 4 Jun 2025 12:08:09 GMT, Per Minborg wrote:
> The newly marked arrays are indeed only updated once. Can we see any
> benchmark showing a performance gain?
I ran `make test TEST="micro:java.math.BigDecimals` on a MacBook M1 Pro, and
there was no performance improvement with the Stable a
On Wed, 4 Jun 2025 14:03:49 GMT, Raffaello Giulietti
wrote:
>> Please do _not_ fix the `mag` issue in this PR.
>> I'll take care of it in a future PR.
>
> I just filed [JDK-8358599](https://bugs.openjdk.org/browse/JDK-8358599).
> Please do _not_ fix the `mag` issue in this PR. I'll take care of
> Some static final arrays of BigInteger and BigDecimal are stable and
> immutable. We should add `@Stable` to give the optimizer more information
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 c
On Mon, 2 Jun 2025 18:23:25 GMT, Per Minborg wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> BigInteger::mag remove Stable
>
> A general comment with respect to `@Stable` is that it
On Fri, 30 May 2025 14:01:04 GMT, Roger Riggs wrote:
> Comment out assertions added in JDK-8351443 from
> AbstractStringBuilder.ensureCapacityNewCoder that increase the codesize,
> preventing some inlining, and reducing performance
>
>assert coder == newCoder || newCoder == UTF16 : "ba
On Fri, 30 May 2025 21:36:52 GMT, ExE Boss wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> bug fix, from @minborg
>
> src/java.base/share/classes/java/math/BigInteger.java line 192:
> Some static final arrays of BigInteger and BigDecimal are stable and
> immutable. We should add `@Stable` to give the optimizer more information
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
BigInteger::mag remove
On Sat, 24 May 2025 10:00:56 GMT, Shaojin Wen wrote:
> Classes such as java.lang.CharacterDataXXX have multiple static final arrays,
> these are immutable, We should add `@Stable` and final to provide information
> to the optimizer.
This pull request has now been integrated.
On Wed, 28 May 2025 19:20:08 GMT, ExE Boss wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix comments, from @natoj
>
> src/java.base/share/classes/java/lang/CharacterData00.java.temp
On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen wrote:
> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will
> call the DigitList::toString method. At this time, DigitList::toString will
> modify tempBuilder, which will cause incorrect results.
This pull reques
> Some static final arrays of BigInteger and BigDecimal are stable and
> immutable. We should add `@Stable` to give the optimizer more information
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
bug fix, from @m
Some static final arrays of BigInteger and BigDecimal are stable and immutable.
We should add `@Stable` to give the optimizer more information
-
Commit messages:
- BigInteger::mag add `@Stable`
- add stable
Changes: https://git.openjdk.org/jdk/pull/25437/files
Webrev: https://we
On Tue, 27 May 2025 19:31:44 GMT, Volkan Yazici wrote:
> _Nit:_ Would it be an overkill to add a test (verifying `toString` doesn't
> spoil the content) to avoid falling on the same slippery slope (i.e., _"Let
> me optimize this by reusing the `SB`!"_) again?
The original code that calls getSt
On Tue, 27 May 2025 17:11:41 GMT, Johannes Döbler wrote:
>> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will
>> call the DigitList::toString method. At this time, DigitList::toString will
>> modify tempBuilder, which will cause incorrect results.
>
> src/java.base/sha
> Classes such as java.lang.CharacterDataXXX have multiple static final arrays,
> these are immutable, We should add `@Stable` and final to provide information
> to the optimizer.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revisio
On Tue, 27 May 2025 16:50:40 GMT, Naoto Sato wrote:
> Nice refactoring. As to C-style array rewrite, I am not so keen on that as
> they only appear in the generated source files, without any actual benefit.
You and @cl4es both mentioned this, and I agree, but it should be another PR to
remove
g
> constructor
>
>
> String(Charset charset, byte[] bytes, int offset, int length) {}
>
> The above String constructor is too large; break it down into smaller methods
> with a codeSize under 325 to allow them to be inlined by the C2.
Shaojin Wen has updated the pull requ
g
> constructor
>
>
> String(Charset charset, byte[] bytes, int offset, int length) {}
>
> The above String constructor is too large; break it down into smaller methods
> with a codeSize under 325 to allow them to be inlined by the C2.
Shaojin Wen has updated the pull requ
> Classes such as java.lang.CharacterDataXXX have multiple static final arrays,
> these are immutable, We should add `@Stable` and final to provide information
> to the optimizer.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revisio
On Sat, 24 May 2025 02:30:16 GMT, Shaojin Wen wrote:
> Integer::digits type can use byte[] instead of char[], which can reduce the
> conversion from char to byte in the process of Integer.toString. Using byte[]
> can also save memory.
This pull request has now been integrated.
On Sun, 25 May 2025 04:39:24 GMT, Chen Liang wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> create method share variant val & coder
>
> src/java.base/share/classes/java/la
g
> constructor
>
>
> String(Charset charset, byte[] bytes, int offset, int length) {}
>
> The above String constructor is too large; break it down into smaller methods
> with a codeSize under 325 to allow them to be inlined by the C2.
Shaojin Wen has updated the pull requ
g
> constructor
>
>
> String(Charset charset, byte[] bytes, int offset, int length) {}
>
> The above String constructor is too large; break it down into smaller methods
> with a codeSize under 325 to allow them to be inlined by the C2.
Shaojin Wen has updated the pull requ
On Sun, 25 May 2025 04:40:44 GMT, Chen Liang wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> create method share variant val & coder
>
> src/java.base/share/classes/java/la
On Sat, 24 May 2025 23:04:50 GMT, Chen Liang wrote:
>> Classes such as java.lang.CharacterDataXXX have multiple static final
>> arrays, which will not be modified. We should add @Stable to provide
>> information to the optimizer.
>
> make/jdk/src/classes/build/tools/generatecharacter/GenerateCh
Classes such as java.lang.CharacterDataXXX have multiple static final arrays,
which will not be modified. We should add @Stable to provide information to the
optimizer.
-
Commit messages:
- sealed & final
- add @Stable
- stable
Changes: https://git.openjdk.org/jdk/pull/25430/fil
On Thu, 15 May 2025 22:03:22 GMT, Shaojin Wen wrote:
> In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove
> these methods
This pull request has now been integrated.
Changeset: b0373537
Author:Shaojin Wen
URL:
https://git.openjdk.org/jdk/
> Integer::digits type can use byte[] instead of char[], which can reduce the
> conversion from char to byte in the process of Integer.toString. Using byte[]
> can also save memory.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last
Integer::digits type can use byte[] instead of char[], which can reduce the
conversion from char to byte in the process of Integer.toString. Using byte[]
can also save memory.
-
Commit messages:
- char[] -> byte[]
Changes: https://git.openjdk.org/jdk/pull/25426/files
Webrev: htt
When debugging getLong/getDouble/getDecimal of DigitList, the debugger will
call the DigitList::toString method. At this time, DigitList::toString will
modify tempBuilder, which will cause incorrect results.
-
Commit messages:
- minimal change
- remove tempBuilder
Changes: https:
On Mon, 12 May 2025 11:27:35 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which addresses the issue noted in
>> https://bugs.openjdk.org/browse/JDK-8354799?
>>
>> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero
>> size was missing a CRC check f
> In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove
> these methods
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains two commits:
- Merge remote-tracking branch 'upstream/m
On Mon, 6 Jan 2025 13:18:50 GMT, Shaojin Wen wrote:
> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD
> within a register) instead of table lookup. Eliminating the table lookup can
> also avoid the performance degradation problem when the cache misses.
On Thu, 22 May 2025 08:14:35 GMT, Per Minborg wrote:
>> This PR builds on a concept John Rose told me about some time ago. Instead
>> of combining memory operations of various sizes, a single large and skewed
>> memory operation can be made to clean up the tail of remaining bytes.
>>
>> This h
On Thu, 22 May 2025 08:11:09 GMT, Per Minborg wrote:
>> This PR builds on a concept John Rose told me about some time ago. Instead
>> of combining memory operations of various sizes, a single large and skewed
>> memory operation can be made to clean up the tail of remaining bytes.
>>
>> This h
On Wed, 21 May 2025 21:19:36 GMT, Justin Lu wrote:
> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data
> carrier for Locale. The class, once created is not modified; the class should
> be made immutable. Converting the class to a record accomplishes this and
> also simplif
> The byte[] allocated in Integer/Long.toString is fully filled, so we can use
> StringConcatHelper::newArray to create byte[] 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 11 commits:
-
On Thu, 15 May 2025 06:24:44 GMT, Shaojin Wen wrote:
> Similar to PR #24982
> Document preconditions on certain DecimalDigits methods that use operations
> either unsafe and/or without range checks.
This pull request has now been integrated.
Changeset: 07871cd7
Author: Shaojin
> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD
> within a register) instead of table lookup. Eliminating the table lookup can
> also avoid the performance degradation problem when the cache misses.
Shaojin Wen has updated the pull request incrementally
> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD
> within a register) instead of table lookup. Eliminating the table lookup can
> also avoid the performance degradation problem when the cache misses.
Shaojin Wen has updated the pull request incrementally
On Mon, 12 May 2025 11:27:35 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which addresses the issue noted in
>> https://bugs.openjdk.org/browse/JDK-8354799?
>>
>> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero
>> size was missing a CRC check f
On Tue, 20 May 2025 19:51:14 GMT, Roger Riggs wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> hex8 comments
>
> src/java.base/share/classes/java/util/UUID.java line 528:
>
>
On Tue, 20 May 2025 15:53:34 GMT, Jaikiran Pai wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> warning
>
> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line
On Tue, 20 May 2025 08:26:20 GMT, Per Minborg wrote:
> I wonder if it would be better to first check `COMPACT_STRINGS` in a
> first-level `if` and then branch off to separate support methods? Looking at
> the comments near the declaration of `COMPACT_STRINGS`, this might provide
> additional b
g
> constructor
>
>
> String(Charset charset, byte[] bytes, int offset, int length) {}
>
> The above String constructor is too large; break it down into smaller methods
> with a codeSize under 325 to allow them to be inlined by the C2.
Shaojin Wen has updated the pull requ
g
> constructor
>
>
> String(Charset charset, byte[] bytes, int offset, int length) {}
>
> The above String constructor is too large; break it down into smaller methods
> with a codeSize under 325 to allow them to be inlined by the C2.
Shaojin Wen has updated the pull requ
On Sun, 18 May 2025 20:44:12 GMT, Chen Liang wrote:
>> Through JVM Option +PrintInlining, we found that String has a constructor
>> codeSize of 852, which is too large. This caused failed to inline.
>>
>> The following is the output information of PrintInlining:
>>
>> @ 9 jav
On Sun, 18 May 2025 12:48:07 GMT, Shaojin Wen wrote:
> Through JVM Option +PrintInlining, we found that String has a constructor
> codeSize of 852, which is too large. This caused failed to inline.
>
> The following is the output information of PrintInlining:
>
>
Through JVM Option +PrintInlining, we found that String has a constructor
codeSize of 852, which is too large. This caused failed to inline.
The following is the output information of PrintInlining:
@ 9 java.lang.String:: (12 bytes) inline (hot)
!m @ 1 java.
On Mon, 19 May 2025 18:30:20 GMT, Roger Riggs wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> simplify code
>
> src/java.base/share/classes/java/util/UUID.java line 491:
>
>>
> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD
> within a register) instead of table lookup. Eliminating the table lookup can
> also avoid the performance degradation problem when the cache misses.
Shaojin Wen has updated the pull request incrementally
> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD
> within a register) instead of table lookup. Eliminating the table lookup can
> also avoid the performance degradation problem when the cache misses.
Shaojin Wen has updated the pull request incrementally
On Mon, 19 May 2025 20:17:43 GMT, Shaojin Wen wrote:
>> Improve the performance of UUID::toString by using Long.expand and SWAR
>> (SIMD within a register) instead of table lookup. Eliminating the table
>> lookup can also avoid the performance degradation problem when th
> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD
> within a register) instead of table lookup. Eliminating the table lookup can
> also avoid the performance degradation problem when the cache misses.
Shaojin Wen has updated the pull request with a new ta
On Thu, 15 May 2025 22:03:22 GMT, Shaojin Wen wrote:
> In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove
> these methods
The getCharsLatin1/getCharsUTF16 methods of HexDigits may be used in
j.u.Formatter/HexFormat in the future. For this reason, should we kee
On Fri, 2 May 2025 07:13:21 GMT, Shaojin Wen wrote:
>>> ```java
>>> > char[] ca = new char[end - off];
>>> ```
>>>
>>> Your code here has a memory allocation, which may cause slowdown
>>
>> This is exactly what I wanted to
> Similar to PR #24982
> Document preconditions on certain DecimalDigits methods that use operations
> either unsafe and/or without range checks.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
warning
-
> Similar to PR #24982
> Document preconditions on certain DecimalDigits methods that use operations
> either unsafe and/or without range checks.
Shaojin Wen has updated the pull request incrementally with seven additional
commits since the last revision:
- Update src/java.base/shar
> Similar to PR #24982
> Document preconditions on certain DecimalDigits methods that use operations
> either unsafe and/or without range checks.
Shaojin Wen has updated the pull request incrementally with two additional
commits since the last revision:
- assert
- document add
In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove
these methods
-
Commit messages:
- remove unused code
Changes: https://git.openjdk.org/jdk/pull/25258/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25258&range=00
Issue: https://bugs.openjdk.o
On Thu, 15 May 2025 15:37:39 GMT, fabioromano1 wrote:
>> Some changes in `Biginteger`s' bit operations that increase the code
>> readability and slightly optimize the execution time.
>
> fabioromano1 has updated the pull request incrementally with one additional
> commit since the last revision
On Thu, 15 May 2025 18:12:28 GMT, Raffaello Giulietti
wrote:
> @wenshao I understand this is a kind of followup of #24982, but why this
> title? It seems just renaming some methods with more speaking names.
Yes, it is just a renaming of some methods, the title is followup #24982, does
the sam
Similar to PR #24982
Document preconditions on certain DecimalDigits methods that use operations
either unsafe and/or without range checks.
-
Commit messages:
- Document preconditions for DecimalDigits methods
Changes: https://git.openjdk.org/jdk/pull/25246/files
Webrev: https:/
On Mon, 12 May 2025 18:33:03 GMT, Roger Riggs wrote:
>>> This use of Unsafe is not warranted. If it can't be done with arrayCopy,
>>> leave the original code as is.
>>
>> The core library also uses Unsafe.copyMemory in many places. Can it be used
>> in this scenario? Or can we find other ways
p to
> improve the speed.
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains nine commits:
- copyright
- Merge remote-tracking branch 'upstream/master' into
optim_sb_append_chars_202504
# Conflicts:
On Wed, 7 May 2025 07:46:45 GMT, Per Minborg wrote:
>> This sketch shows how "Stable Updaters" can be used to create stable
>> computations of `@Stable` fields. Only one updater is needed per class,
>> similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incremen
On Mon, 24 Feb 2025 09:46:29 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change, which simplifies the interaction
>> between the `java` launcher's native code with the
>> `sun.launcher.LauncherHelper`?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8341184, this propo
1 - 100 of 1152 matches
Mail list logo
