RFR: 8259842: Remove Result cache from StringCoding

Roger Riggs rriggs at openjdk.java.net
Fri Jan 15 20:19:04 UTC 2021


On Fri, 15 Jan 2021 20:05:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 544:
>> 
>>> 542:             return;
>>> 543:         }
>>> 544:         if (charset == UTF_8) {
>> 
>> The constructor is getting big. Might be better to keep the original private methods (decodeASCII/Latin1/UTF8) for readability.
>
> Since we're calculating two final values, that split was what necessitated a `Result` object. Until valhalla I don't think there's a way to get rid of the performance cost here without putting the bulk of the logic into the constructor.
> 
> Refactoring out some of the logic to utility methods could be a performance neutral way to cut down the complexity, though. E.g.:
>                                  char c = (char)((b1 << 12) ^
>                                                 (b2 <<  6) ^
>                                                 (b3 ^
>                                                  (((byte) 0xE0 << 12) ^
>                                                   ((byte) 0x80 <<  6) ^
>                                                   ((byte) 0x80 <<  0))));
>                                 if (Character.isSurrogate(c)) {
>                                     putChar(dst, dp++, REPL);
>                                 } else {
>                                     putChar(dst, dp++, c);
>                                 }
> could be reasonably factored out and reduced to something like:
>                                 putChar(dst, dp++, StringCoding.decode3(b1, b2, b3));
> I've refrained from refurbishing too much, though.

I don't think you need to inline quite so much.  Once the determination has been made about whether the result is Latin1 or UTF16 it calls separate methods anyway.  For example, after calling hasNegatives() it is known what coding is needed.
Then call out to a method returns the byte array.

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

PR: https://git.openjdk.java.net/jdk/pull/2102


More information about the core-libs-dev mailing list