RFR: 8352869: Verify.checkEQ: extension for NaN, VectorAPI and arbitrary Objects [v3]
Emanuel Peter
epeter at openjdk.org
Fri Mar 28 09:45:24 UTC 2025
On Fri, 28 Mar 2025 05:01:29 GMT, Galder Zamarreño <galder at openjdk.org> wrote:
>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Update test/hotspot/jtreg/compiler/lib/verify/Verify.java
>>
>> Co-authored-by: Galder Zamarreño <galder at redhat.com>
>
> test/hotspot/jtreg/compiler/lib/verify/Verify.java line 79:
>
>> 77: * @throws VerifyException If the comparison fails.
>> 78: */
>> 79: public static void checkEQ(Object a, Object b, boolean isFloatCheckWithRawBits, boolean isCheckWithArbitraryClasses) {
>
> Just a suggestion. One boolean might be ok, but once you start adding 2 booleans it seems like a bit of a code smell to me. Do you envision more options being added? I would personally create a `VerifyOptions` record with the boolean flags options and pass that in.
I'll experiment with a `VerifyOptions`, thanks for the suggestion!
> test/hotspot/jtreg/testlibrary_tests/verify/tests/TestVerify.java line 691:
>
>> 689: }
>> 690:
>> 691: public static void checkNE(Object a, Object b) {
>
> If `checkEQ` lives in Verify, wouldn't it make sense to also have `checkNE` there? Seems like the natural place making the API symmetric.
To be honest, I don't see the need for it being symmetric, i.e. for the API to have a `checkNE`. This `checkNE` method is just a convenience function to check that an exception is thrown if I expect it to.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24224#discussion_r2018254687
PR Review Comment: https://git.openjdk.org/jdk/pull/24224#discussion_r2018253409
More information about the hotspot-compiler-dev
mailing list