<i18n dev> RFR: 8311188: Simplify and modernize equals and hashCode in java.text

[Roger Riggs]

On Tue, 4 Jul 2023 22:03:58 GMT, John R Rose <jrose at openjdk.org> wrote:

>>> Hmm, I think that issue refers to code that have explicit non-Object parameter types (like `X::equals(Object)boolean` in the issue's sample). This method already have both arguments as `Object`, so I don't think there's any type-specific inlining opportunities.
>> 
>> If that's true, then perhaps those (and some other) locations got that idea wrong:
>> * https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/Collections.java#L5712-L5719
>> * https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/AbstractMap.java#L577-L585
>> 
>> Maybe @rose00 could clarify that? 
>> 
>> FWIW, I also note that `HashMap` does not use similar private static methods; it uses `Objects.equals(Object, Object)` and `Objects.hashCode` overloads that take parameters.
>
> I wrote a little case study on `Objects::equals` that talks about how it should optimize, when it does, why it doesn’t, and how (maybe) to fix that.
> 
> https://cr.openjdk.org/~jrose/jvm/equals-profile.html
> https://cr.openjdk.org/~jrose/jvm/equals-profile.md
> 
> This is also attached to the JBS bug.
> 
> The work on [JDK-8026251](https://bugs.openjdk.org/browse/JDK-8026251) with the `TypeProfileLevel` switch bring us closer to correctly optimizing `Objects::equals` in more cases.  Sadly, JDK refactoring by itself will not get all the way to where we want to go.  The JVM’s profiling logic needs tweaking.

I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and remove the `valuesMatch` method as unnecessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1253289975