> It looks like only CharBuffer.getChars is broken so the rest of the change
> can stay. I filed this issue to track it:
>
> https://bugs.openjdk.org/browse/JDK-8361299
>
> The fix is straightforward but will break a test and require a CSR.
Looks like the testNG GetChars has
cb.getChars(cb.posi
n package java.util.regex. The methods defined by
> CharSequence operate relative to the current position of the buffer when they
> are invoked.
https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/CharBuffer.html
On Wed, Jul 2, 2025 at 10:58 AM Brett Okken wrote:
>
/Buffer.html#transferring-data-heading
>
> On Jul 2, 2025, at 8:35 AM, Brett Okken wrote:
>
> CharBuffer implementation of public default void getChars(int
> srcBegin, int srcEnd, char[] dst, int dstBegin) uses absolute
> positioning for the indexes (i.e. ignores the current position).
>
>
:
>
> Hi Brett, I think your suggestion makes sense. I have created
> https://bugs.openjdk.org/browse/JDK-8361209 to track this RFE.
> Feel free to contribute a patch to implement this enhancement.
>
>
> From: core-libs-dev on behalf of Brett Okke
jdk 25 introduced[1] a bulk getChars method to CharSequence[2].
Should StringCharBuffer be updated to utilize that new method to
implement the bulk get method[3]?
That would presumably require changes to the private getArray[4].
I think there could also be changes to putBuffer[5] for when the
targe
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 BufferedWriter
>> layer can be removed. A
On Tue, 1 Jul 2025 00:10:00 GMT, Shaojin Wen 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?
-
PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021453158
On Mon, 30 Jun 2025 23:56:53 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 can be removed.
Maybe another option would be to implement BufferedWriter with a
StringBuilder rather than a char[]. This would remove the force to utf-16
On Sun, Jun 29, 2025 at 10:36 PM Brett Okken
wrote:
> Is StreamEncoder buffering content to only write to the underlying
> OutputStream when some thr
Is StreamEncoder buffering content to only write to the underlying
OutputStream when some threshold is hit? While the layers of conversions
are unfortunate, it seems there could be negative performance implications
of having many extremely small writes (such as 1 character/byte) at a time
to the un
On Fri, 27 Dec 2024 23:24:46 GMT, Chen Liang wrote:
>>> For sure we should use result of `putIfAbsent`
>>
>> Drive-by comment...
>>
>> From what i can infer, the performance regression being addressed here is
>> caused in part by the fact that (for example)
>> `ConcurrentHashMap.computeIfAbse
On Fri, 20 Dec 2024 21:06:16 GMT, Naoto Sato wrote:
>> The change made in
>> [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723) seems innocuous,
>> but it caused this performance regression. Partially reverting the change
>> (ones that involve `computeIfAbsent()`) to the original. Prov
+1 to option A.
Option C is too limiting on uses for the target. It could be added as a
default which calls through to option A, if there is meaningful demand.
Is it a follow up change/PR for various places which would benefit from
using the new method?
On Fri, Oct 25, 2024 at 1:34 PM Markus Kar
On Sun, 6 Oct 2024 17:44:53 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized implemen
On Wed, 11 Sep 2024 13:15:57 GMT, Per Minborg wrote:
>> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java
>> line 244:
>>
>>> 242: return (Architecture.isLittleEndian()
>>> 243: ? Long.numberOfTrailingZeros(x)
>>> 244: : Long.num
On Thu, 5 Sep 2024 17:47:16 GMT, Per Minborg wrote:
>> This PR proposes to improve the performance of `MemorySegment::mismatch` by
>> using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last
On Sat, 20 Jul 2024 13:11:33 GMT, Brett Okken wrote:
>> Shaojin Wen has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Update src/java.base/share/classes/java/lang/String.java
>>
>>Co-authore
On Fri, 19 Jul 2024 21:42:09 GMT, Shaojin Wen wrote:
>> Currently simpleConcat is implemented using mix and prepend, but in this
>> simple scenario, it can be implemented in a simpler way and can improve
>> performance.
>
> Shaojin Wen has updated the pull request incrementally with two additio
On Thu, 18 Jul 2024 11:32:47 GMT, Shaojin Wen wrote:
> class LocalTime {
> public String toString() {
> // ...
> if (nanoValue % 1000_000 == 0) {
> buf.append(Integer.toString((nanoValue / 1000_000) +
> 1000).substring(1));
> } else
On Sat, 8 Jun 2024 06:40:39 GMT, Shaojin Wen wrote:
>> After PR #16245, C2 optimizes stores into primitive arrays by combining
>> values into larger stores. In the UUID.toString method,
>> ByteArrayLittleEndian can be removed, making the code more elegant and
>> faster.
>
> Shaojin Wen has u
On Sat, 8 Jun 2024 06:40:39 GMT, Shaojin Wen wrote:
>> After PR #16245, C2 optimizes stores into primitive arrays by combining
>> values into larger stores. In the UUID.toString method,
>> ByteArrayLittleEndian can be removed, making the code more elegant and
>> faster.
>
> Shaojin Wen has u
ress
> inputs in the int range. Since it’s all guarded by a test that is already
> there there shouldn’t be much room for a difference, but adding code can
> cause interesting issues so it’s always worth measuring to make sure. Have
> you run any benchmark for inputs smaller than the t
Is there interest in optimizing StringLatin1.getChars(long, int, byte[])
for large (larger than int) long values[1]?
We can change this to work with 8 digits at a time, which reduces the
amount of 64 bit arithmetic required.
if (i <= -1_000_000_000) {
long q = i / 100_000_000;
charPos -= 8;
wri
On Fri, 12 Apr 2024 10:19:27 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line
>> 1430:
>>
>>> 1428: cb.new_(STRING_BUILDER);
>>> 1429: cb.dup();
>>> 1430: cb.invokespecial(STRING_
On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad wrote:
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
> all-or-noth
On Wed, 6 Dec 2023 00:52:48 GMT, Brett Okken wrote:
> The static AtomicInteger used for the nextHashCode should be final.
This pull request has now been integrated.
Changeset: c42535f1
Author: Brett Okken
Committer: Aleksey Shipilev
URL:
https://git.openjdk.org/jdk/com
> The static AtomicInteger used for the nextHashCode should be final.
Brett Okken has updated the pull request incrementally with one additional
commit since the last revision:
Update full name
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16987/files
- new: ht
The static AtomicInteger used for the nextHashCode should be final.
-
Commit messages:
- Merge remote-tracking branch 'upstream/master' into threadlocal_final
- make ThreadLocal.nextHashCode final
Changes: https://git.openjdk.org/jdk/pull/16987/files
Webrev: https://webrevs.openjd
Should the private static AtomicInteger nextHashCode also be final?
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ThreadLocal.java#L100
On Thu, 30 Nov 2023 20:46:12 GMT, Naoto Sato wrote:
> Removing the unnecessary array assignments.
src/java.base/share/classes/sun/text/CompactByteArray.java line 83:
> 81: for (i = 0; i < UNICODECOUNT; ++i) {
> 82: values[i] = defaultValue;
> 83: }
shoul
On Fri, 16 Jun 2023 17:18:38 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 175:
>>
>>> 173:
>>> LocaleUtils.toLowerString(b.getLanguage()).intern(),
>>> 174:
>>> LocaleUtils.toTitleString(b.get
On Fri, 16 Jun 2023 17:18:33 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 168:
>>
>>> 166: // BaseLocale as the key. The returned "normalized" instance
>>> 167: // can subsequently be used by the Locale instance which
>>> 168:
On Tue, 13 Jun 2023 17:56:57 GMT, Naoto Sato wrote:
>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211
>> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored
>> the in-house cache with WeakHashMap, and removed the Key class as it is no
>> longer ne
On Tue, 13 Jun 2023 17:56:57 GMT, Naoto Sato wrote:
>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211
>> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored
>> the in-house cache with WeakHashMap, and removed the Key class as it is no
>> longer ne
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 footprint
> benchmar
On Thu, 1 Jun 2023 09:37:29 GMT, Aleksey Shipilev wrote:
>> UUID is the very important class that is used to track identities of objects
>> in large scale systems. On some of our systems, `UUID.randomUUID` takes >1%
>> of total CPU time, and is frequently a scalability bottleneck due to
>> `Se
On Wed, 24 May 2023 19:36:44 GMT, Aleksey Shipilev wrote:
> UUID is the very important class that is used to track identities of objects
> in large scale systems. On some of our systems, `UUID.randomUUID` takes >1%
> of total CPU time, and is frequently a scalability bottleneck due to
> `Secur
; [2] https://github.com/openjdk/jdk/pull/12076
>
> On 3/1/23 7:50 AM, Brett Okken wrote:
> > Is there any interest in updating the static UUID.randomUUID() and
> > UUID.nameUUIDFromBytes(byte[]) factory methods to use either a
> > ByteBuffer or byteArrayViewVarHandle to conve
Is there any interest in updating the static UUID.randomUUID() and
UUID.nameUUIDFromBytes(byte[]) factory methods to use either a
ByteBuffer or byteArrayViewVarHandle to convert the byte[] to 2 long
values then do the bit twiddling?
These methods are really dominated by time to create/populate the
Once a
> non-ASCII char is encountered we fall back to the slow loop and replace as
> needed.
>
> An alternative could be unrolling or using a byte array VarHandle, as
> show-cased by Brett Okken here:
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-February/100573.html
oding
> failures. That loop could still benefit from unrolling or
> byteArrayViewVarHandle, but I think you have a bigger problem in an app
> than raw performance if you have a lot of encoding failures...)
>
> WDYT?
>
> /Claes
>
> 18 feb. 2023 kl. 19:36 skrev Brett Okken :
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L976-L981
For String.encodeASCII, with the LATIN1 coder is there any interest in
exploring the performance impacts of utilizing a
byteArrayViewVarHandle to read/write as longs and utilize a bitmask to
iden
On Fri, 2 Dec 2022 12:44:18 GMT, Sergey Tsypanov wrote:
> I found out that this code
>
> public class Main {
> public static void main(String[] args) {
> String s = "Hello world!";
> char[] chars = s.toCharArray();
> int point = Character.codePointAt(chars, -1, 1);
>
43 matches
Mail list logo
