RFR: 8259842: Remove Result cache from StringCoding

[Roger Riggs]

On Fri, 15 Jan 2021 20:14:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> 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.

(Also, every email is very long because it includes the performance data; next time please put the performance data in a separate comment, not the PR).

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

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