Chen,
I do not like the idea to prepare a solution that is more or less
speculative (without the actual conflicts at hand, we cannot *measure*
its actual impact). The current solution is *proven* to be effective
as-is, as I could *measure* it. I think it is the better approach to go
with the current solution as-is meanwhile, hence merge that, and once
your assumed conflicts actually arise I will adapt the solution in a way
that is *proven* to be superior (as it could get *measured* then). Also
I would be happy to work with that other people so a possibly needed
adaption could happen directly in their branch - once somebody tells me
who those people are. I do not see why *not* going that two-steps route
(so we can have my optimization right now, and the other optimization
*once it is actually done*). There is no need to delay the first
step. But maybe I am missing something?
-Markus
Am 09.04.2026 um 05:54 schrieb Chen Liang:
I think what that endpoint will want is that operations taking
|CharSequence| has a string or stringbuilder/buffer fast path. You
just need to design the rewrite so that all CharSequence paths can
support the string/stringbuffer/builder fast paths. I think what that
means is the actual getChars call should be done in a shared private
method, so the callers can, in the future, determine if their char
sequence can support that fast path and avoid calling the getChars path.
------------------------------------------------------------------------
*From:* Markus KARG <[email protected]>
*Sent:* Wednesday, April 8, 2026 11:32 AM
*To:* Chen Liang <[email protected]>; 'core-libs-dev'
<[email protected]>
*Subject:* Re: [External] : Re: 8377939: Improving efficiency of
StreamEncoder::append(CharSequence) and StreamEncoder::(CharSequence,
int, int)
I will look into such conflicts as soon as there are some. Currently
there are none. Can you point me to that work in progress so I can
take proceed?
Am 07.04.2026 um 17:26 schrieb Chen Liang:
Hi Markus,
I think there are other proposed enhancements to StreamEncoder that
conflicts with your proposal of using char[] - one I heard of
proposes using LATIN1 byte[] of a String directly to avoid redundant
costs from expanding to char, given often times the output char set
is often UTF-8 too.
I think you may need to figure out a way to handle such conflicts;
most likely your optimization would have to yield to the LATIN1
passthrough optimization when they conflict.
Regards,
Chen
------------------------------------------------------------------------
*From:* core-libs-dev <[email protected]>
<mailto:[email protected]> on behalf of Markus KARG
<[email protected]> <mailto:[email protected]>
*Sent:* Sunday, March 1, 2026 3:28 AM
*To:* 'core-libs-dev' <[email protected]>
<mailto:[email protected]>
*Subject:* [External] : Re: 8377939: Improving efficiency of
StreamEncoder::append(CharSequence) and StreamEncoder::(CharSequence,
int, int)
Chen,
I developed this code after you triggered me to do so one year ago, and
would like to contribute it now. As Alan told me back then, I must not
file a Pull Request without prior discussion on the core-libs mailing
list. As nobody responded so far, I kindly ask for your personal
agreement on the mailing list to proceed with a PR, so we can progress
towards your proposed usage of CharSequence::getChars() within OpenJDK
itself. A short public confirmation that you like to see such a PR would
be enough IMHO.
Thank you!
-Markus
Am 21.02.2026 um 17:32 schrieb Markus KARG:
> Core-Lib Devs,
>
> as proposed in https://bugs.openjdk.org/browse/JDK-8377939
<https://bugs.openjdk.org/browse/JDK-8377939> I would
> like to improve efficiency of StreamEncoder::append(CharSequence) (and
> in turn OutputStreamWriter::append(CharSequence)) for non-String and
> non-CharBuffer values, which seems to be safe and simple:
>
> * No API or behavior is changed.
> * StreamEncoder is final and is only used internally of OpenJDK, and
> is not leaked.
> * AFAIK the proposed change has no side effects other than being
> potentially more efficient.
> * Only few classes make actual use of StreamEncoder;
> OutputStreamWriter is probably the most popular one, and immediately
> provides potential benefit to I/O-bound applications dealing with
> StringBuilder-crafted output.
>
> I have meanwhile coded the change (see diff at
>
https://github.com/openjdk/jdk/compare/master...mkarg:jdk:StreamEncoder-uses-CharsSequence-getChars)
<https://urldefense.com/v3/__https://github.com/openjdk/jdk/compare/master...mkarg:jdk:StreamEncoder-uses-CharsSequence-getChars)__;!!ACWV5N9M2RV99hQ!JCOIF7stnz9JaDW2Buefa2nqGH9PpvUezC1h2tHmxCv0q5C8aHQvkxqELwuPfSQ5XFZXq3thg7AqjDgkuTnNHM8$>
> and tested it successfully using OpenJDK Github Actions (see result at
> https://github.com/mkarg/jdk/actions/runs/22259626078)
<https://urldefense.com/v3/__https://github.com/mkarg/jdk/actions/runs/22259626078)__;!!ACWV5N9M2RV99hQ!JCOIF7stnz9JaDW2Buefa2nqGH9PpvUezC1h2tHmxCv0q5C8aHQvkxqELwuPfSQ5XFZXq3thg7AqjDgk4NCWg4Q$>.
>
> Are you fine with me opening a Pull Request on Github?
>
> Thanks!
>
> -Markus
>
