RFR: 8352869: Verify.checkEQ: extension for NaN, VectorAPI and arbitrary Objects [v5]
Christian Hagedorn
chagedorn at openjdk.org
Mon Mar 31 14:07:26 UTC 2025
On Mon, 31 Mar 2025 08:57:33 GMT, Emanuel Peter <epeter at openjdk.org> wrote:
>> We should extend the functionality of Verify.checkEQ:
>> - Allow different NaN encodings to be seen as equal (by default).
>> - Compare VectorAPI vectors.
>> - Compare Exceptions, and their messages.
>> - Compare arbitrary Objects via Reflection.
>>
>> Note: this is a prerequisite for the Template Library [JDK-8352861](https://bugs.openjdk.org/browse/JDK-8352861) / https://github.com/openjdk/jdk/pull/23418.
>
> Emanuel Peter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>
> - Merge branch 'master' into JDK-8352869-Verify-NaN-Vector-Objects
> - Verify.Options refactor for Galder
> - Update test/hotspot/jtreg/compiler/lib/verify/Verify.java
>
> Co-authored-by: Galder Zamarreño <galder at redhat.com>
> - Merge branch 'master' into JDK-8352869-Verify-NaN-Vector-Objects
> - clean up test
> - JDK-8352869
Nice extensions! Some initial comments.
test/hotspot/jtreg/compiler/lib/verify/Verify.java line 25:
> 23:
> 24: package compiler.lib.verify;
> 25:
You should update the copyright year.
test/hotspot/jtreg/compiler/lib/verify/Verify.java line 37:
> 35: /**
> 36: * The {@link Verify} class provides {@link Verify#checkEQ}, which recursively compares the two
> 37: * {@link Object}s by value. It deconstructs {@link Object[]}, compares boxed primitive types,
Can be any object array right? I would instead write:
Suggestion:
* {@link Object}s by value. It deconstruct an array of objects, compares boxed primitive types,
test/hotspot/jtreg/compiler/lib/verify/Verify.java line 43:
> 41: *
> 42: * <p>
> 43: * When a comparison fail, then methods print helpful messages, before throwing a {@link VerifyException}.
Suggestion:
* When a comparison fails, then methods print helpful messages, before throwing a {@link VerifyException}.
test/hotspot/jtreg/compiler/lib/verify/Verify.java line 46:
> 44: *
> 45: * <p>
> 46: * We have to take special care of {@link Float}s and {@link Double}s, since they have both various
Suggestion:
* We have to take special care of {@link Float}s and {@link Double}s, since they both have various
test/hotspot/jtreg/compiler/lib/verify/Verify.java line 47:
> 45: * <p>
> 46: * We have to take special care of {@link Float}s and {@link Double}s, since they have both various
> 47: * encodings for NaN values, but on Java specification they are to be regarded as equal. Hence, we
Suggestion:
* encodings for NaN values while the Java specification regards them as equal. Hence, we
test/hotspot/jtreg/compiler/lib/verify/Verify.java line 68:
> 66:
> 67: /**
> 68: * Generates a {@link Options} with default settings.
Suggestion:
* Generates an {@link Options} object with default settings.
test/hotspot/jtreg/compiler/lib/verify/Verify.java line 86:
> 84: * By default, we only support the comparison of a limited set of types, but with this option
> 85: * enabled, we can compare arbitrary classes by value, and we compare the Objects by
> 86: * the recursive structore given by their field values.
Suggestion:
* the recursive structure given by their field values.
test/hotspot/jtreg/compiler/lib/verify/Verify.java line 209:
> 207: print(a, b, field, aParent, bParent);
> 208: throw new VerifyException("Object type not supported: " + ca.getName() + " -- did you mean to 'enableCheckWithArbitraryClasses'?");
> 209: }
What's the reason behind throwing instead of just comparing two arbitrary objects by default? If a user calls `Verify.checkEQ()` and sees this exception, I would guess he then just passes the additional option and we have the same result. But maybe I'm missing something.
-------------
PR Review: https://git.openjdk.org/jdk/pull/24224#pullrequestreview-2729239101
PR Review Comment: https://git.openjdk.org/jdk/pull/24224#discussion_r2021016321
PR Review Comment: https://git.openjdk.org/jdk/pull/24224#discussion_r2021029237
PR Review Comment: https://git.openjdk.org/jdk/pull/24224#discussion_r2021029655
PR Review Comment: https://git.openjdk.org/jdk/pull/24224#discussion_r2021030792
PR Review Comment: https://git.openjdk.org/jdk/pull/24224#discussion_r2021032586
PR Review Comment: https://git.openjdk.org/jdk/pull/24224#discussion_r2021039554
PR Review Comment: https://git.openjdk.org/jdk/pull/24224#discussion_r2021040835
PR Review Comment: https://git.openjdk.org/jdk/pull/24224#discussion_r2021108161
More information about the hotspot-compiler-dev
mailing list