On Wed, 5 Aug 2026 12:03:13 GMT, Marc Chevalier <[email protected]> wrote:

>> src/hotspot/share/opto/inlinetypenode.cpp line 1055:
>> 
>>> 1053:       Node* la = make_load(offset, TypeLong::LONG, T_LONG);
>>> 1054:       result = kit->AddI(kit->MulI(thirty_one, result), 
>>> kit->ConvL2I(la));
>>> 1055:       result = kit->AddI(kit->MulI(thirty_one, result), 
>>> kit->ConvL2I(kit->URShiftL(la, kit->intcon(32))));
>> 
>> Note that as was suggested in 
>> <https://github.com/openjdk/jdk/pull/31123#discussion_r3354053360> (and 
>> [JDK‑8388062]), this and `ValueObjectMethods​::valueObjectHashCode(…)` 
>> should probably be updated to use the same computation as `Long::hashCode`.
>> 
>> [JDK‑8388062]: https://bugs.openjdk.org/browse/JDK-8388062
>
> That's true! But that is a discussion that would involve people with more 
> stake (and rightfully stronger opinions) than me. And I suspect changing how 
> the hash is computed is not a priority for those people as long as the 
> current version is good enough (which is very understandable!).
> 
> Since it would be easy to change the compiler parts if needed, it was decided 
> not to block this PR on a decision that is not likely to come very quickly. 
> Also I don't think it'd be very nice to both add the compiler improvements at 
> the same time as a modification in the behavior.

I think compiler people should pick the easiest way to compute a hash and have 
core libs/interpreter etc. settle on that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/32144#discussion_r3724539303

Reply via email to