On Sat, 12 Nov 2022 01:28:51 GMT, Vladimir Ivanov <vliva...@openjdk.org> wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Missing & 0xff in StringLatin1::hashCode
>
> src/hotspot/share/opto/intrinsicnode.hpp line 175:
>
>> 173: // as well as adjusting for special treatment of various encoding of
>> String
>> 174: // arrays. Must correspond to declared constants in
>> jdk.internal.util.ArraysSupport
>> 175: typedef enum HashModes { LATIN1 = 0, UTF16 = 1, BYTE = 2, CHAR = 3,
>> SHORT = 4, INT = 5 } HashMode;
>
> I question the need for `LATIN1` and `UTF16` modes. If you lift some of input
> adjustments (initial value and input size) into JDK, it becomes
> indistinguishable from `BYTE`/`CHAR`. Then you can reuse existing constants
> for basic types.
UTF16 can easily be replaced with CHAR by lifting up the shift as you say, but
LATIN1 needs to be distinguished from BYTE since the former needs unsigned
semantics. Modeling in a signed/unsigned input is possible, but I figured we
might as well call it UNSIGNED_BYTE and decouple it logically from
String::LATIN1.
-------------
PR: https://git.openjdk.org/jdk/pull/10847
