[lworld] RFR: 8366214: [lworld] Use Objects.equals in HashMap and ConcurrentHashmap

[Roger Riggs]

On Wed, 27 Aug 2025 22:21:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As observed in [JDK-8366043](https://bugs.openjdk.org/browse/JDK-8366043) [lworld] (LIFE = Legacy Idiom For Equality) causes performance regressions.
>> Updating HashMap and ConcurrentHashMap to use `java.util.Objects.equals` will make it easier to measure performance of options that remove or modify the use of `==`
>> 
>> Replace constructs like:
>> 
>> -                        ((k = e.key) == key || (key != null && key.equals(k))))
>> with:
>> +                        Objects.equals(key, k))
>> 
>> 
>> The changes in ConcurrentHashMap are a bit different due to the use of null as a sentinel.
>> 
>> The order of arguments to the .equals methods must remain the same to ensure compatibility.
>
> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 682:
> 
>> 680:                     K ek;
>> 681:                     if (e.hash == h &&
>> 682:                         (ek = e.key) != null && Objects.equals(k, ek))
> 
> Looking at the code in HashMap, I think you can just use `Objects.equals(k, ek = e.key)`, or just `k.equals(ek = e.key)` because `Object::equals` is supposed to return false on null.

HashMap allows null keys and that is handled separately in each case, not by the `equals` method.
"supposed to" is not sufficient when compatibility is concerned.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1536#discussion_r2307434641