RFR: 8352869: Verify.checkEQ: extension for NaN, VectorAPI and arbitrary Objects [v5]

[Emanuel Peter]

On Mon, 31 Mar 2025 09:28:27 GMT, Galder Zamarreño <galder at openjdk.org> wrote:

>> 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
>
> test/hotspot/jtreg/compiler/lib/verify/Verify.java line 297:
> 
>> 295:     private void checkEQimpl(float a, float b, String field, Object aParent, Object bParent) {
>> 296:         if (isFloatEQ(a, b)) {
>> 297:             System.err.println("ERROR: Verify.checkEQ failed: value mismatch. check raw: " + verifyOptions.isFloatCheckWithRawBits);
> 
> I meant using JEP 378 text blocks, e.g.
> 
> Suggestion:
> 
> System.err.printf("""
>     ERROR: Verify.checkEQ failed: value mismatch. check raw: %b
>       Values: %.1f vs %.1f
>       Raw:    %d vs %d
>     """, isFloatCheckWithRawBits, a, b, Float.floatToRawIntBits(a), Float.floatToRawIntBits(b));

I see.

That has advantages and disadvantages.
Advantage: You can more easily see the "skeleton" of the test.
Disadvantage: Mapping the "holes" and the "values" is annoying, you basically have to count through each position. Plus it may end up being more lines.

Best would really be String Templates.

I asked @chhagedorn , he does not have an opinion either way.

Personally, I prefer my way, where you can easily see what values go where directly. But this is probably a taste question.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24224#discussion_r2020873454