8352869: Verify.checkEQ: extension for NaN, VectorAPI and arbitrary Objects #24224

eme64 · 2025-03-25T11:15:58Z

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 / #23418.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8352869: Verify.checkEQ: extension for NaN, VectorAPI and arbitrary Objects (Enhancement - P4)

Reviewers

Christian Hagedorn (@chhagedorn - Reviewer)
Tobias Hartmann (@TobiHartmann - Reviewer) Review applies to 49f6789c

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/24224/head:pull/24224
$ git checkout pull/24224

Update a local copy of the PR:
$ git checkout pull/24224
$ git pull https://git.openjdk.org/jdk.git pull/24224/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 24224

View PR using the GUI difftool:
$ git pr show -t 24224

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/24224.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-03-25T11:16:42Z

👋 Welcome back epeter! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-03-25T11:17:32Z

@eme64 This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8352869: Verify.checkEQ: extension for NaN, VectorAPI and arbitrary Objects

Reviewed-by: chagedorn, thartmann

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 14 new commits pushed to the master branch:

e09d2e2: 8288471: java/awt/ScrollPane/bug8077409Test.java is unstable and fails intermittently in CI
64b58f6: 8356089: java/lang/IO/IO.java fails with -XX:+AOTClassLinking
7f6ea27: 8356020: Failed assert in virtualMemoryTracker.cpp
... and 11 more: https://git.openjdk.org/jdk/compare/1501a5e41e59162a374cf5b8cfc37faced48a6ed...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2025-03-25T11:18:25Z

@eme64 The following label will be automatically applied to this pull request:

hotspot-compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2025-03-25T11:27:32Z

Webrevs

test/hotspot/jtreg/compiler/lib/verify/Verify.java

galderz · 2025-03-28T05:01:29Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

     */
-    public static void checkEQ(Object a, Object b) {
-        checkEQ(a, b, "");
+    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!

galderz · 2025-03-28T05:04:42Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

+     */
+    private void checkEQimpl(float a, float b, String field, Object aParent, Object bParent) {
+        if (isFloatEQ(a, b)) {
+            System.err.println("ERROR: Verify.checkEQ failed: value mismatch. check raw: " + isFloatCheckWithRawBits);


Would using a text block here make it more readable?

@galderz What do you mean by a text block? String Templates would be nice, but we don't have them. Do you mean I should use String.format? But there is always so tricky to know what is going to be formatted to where...

galderz · 2025-03-28T05:04:56Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

-            System.err.println("ERROR: Verify.checkEQ failed: value mismatch for " + context);
+    private void checkEQimpl(double a, double b, String field, Object aParent, Object bParent) {
+        if (isDoubleEQ(a, b)) {
+            System.err.println("ERROR: Verify.checkEQ failed: value mismatch. check raw: " + isFloatCheckWithRawBits);


Same text block comment here

galderz · 2025-03-28T05:06:28Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

+    }
+
+    private void print(Object a, Object b, String field, Object aParent, Object bParent) {
+        System.err.println("  aParent: " + aParent);


Text block?

galderz · 2025-03-28T05:10:35Z

test/hotspot/jtreg/testlibrary_tests/verify/tests/TestVerify.java

        } catch (VerifyException e) {}
    }
+
+    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.

Co-authored-by: Galder Zamarreño <[email protected]>

eme64 · 2025-03-28T10:53:44Z

@galderz Thanks for the comments! I think I addressed / answered all of them. Could you please have another look? :)

galderz · 2025-03-31T09:28:27Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

+     */
+    private void checkEQimpl(float a, float b, String field, Object aParent, Object bParent) {
+        if (isFloatEQ(a, b)) {
+            System.err.println("ERROR: Verify.checkEQ failed: value mismatch. check raw: " + verifyOptions.isFloatCheckWithRawBits);


I meant using JEP 378 text blocks, e.g.

Suggested change

System.err.println("ERROR: Verify.checkEQ failed: value mismatch. check raw: " + verifyOptions.isFloatCheckWithRawBits);

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.

chhagedorn

Nice extensions! Some initial comments.

chhagedorn · 2025-03-31T13:08:42Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

 */

 package compiler.lib.verify;



You should update the copyright year.

test/hotspot/jtreg/compiler/lib/verify/Verify.java

chhagedorn · 2025-03-31T14:02:15Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

+                if (verifyOptions.isCheckWithArbitraryClasses) {
+                    checkEQArbitraryClasses(a, b);
+                    return;
+                } else {
+                    System.err.println("ERROR: Verify.checkEQ failed: type not supported: " + ca.getName());
+                    print(a, b, field, aParent, bParent);
+                    throw new VerifyException("Object type not supported: " + ca.getName() + " -- did you mean to 'enableCheckWithArbitraryClasses'?");
+                }


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.

Good question. I think my reasoning was that comparing arbitrary classes requires reflection. And that is rather slow. So by default it would be good if that feature is not enabled, so the user tries to avoid it, and is aware when they enable it explicitly.

But if you think that is not useful, I can remove the feature.

@chhagedorn what do you think?

I think the intention to let the user double check is good. I'm not sure though if the user is really aware of the potential slow down without diving deeper into the implementation. All they know is that checkEQ somehow does not support their some objects but there is a simple workaround to still use it. So, the real question is: How many users will then consider doing something different when facing this exception and not just enable it anyway? I guess enabling is probably the most natural thing to do.

Given that, I would probably just drop this. It would also simplify the API usage in the following way:

We would only have checks with NaNs being all equals and comparing raw bits (i.e. NaNs not equal). Then you could offer checkEQ() (default) and checkRawBitsEQ() or something like that. Then users do not need to worry about creating and passing in an Options.

What do you think about these suggestions?

What we could do either way at the checkEQ() API method: Describe the potential slow down with reflection when not using certain classes.

Co-authored-by: Christian Hagedorn <[email protected]>

eme64 · 2025-04-01T07:02:52Z

@chhagedorn Thanks for the suggestions and questions! I think I addressed them all :)

chhagedorn

I'll have a closer look at the code later again :-)

chhagedorn · 2025-04-01T09:06:35Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

+                if (verifyOptions.isCheckWithArbitraryClasses) {
+                    checkEQArbitraryClasses(a, b);
+                    return;
+                } else {
+                    System.err.println("ERROR: Verify.checkEQ failed: type not supported: " + ca.getName());
+                    print(a, b, field, aParent, bParent);
+                    throw new VerifyException("Object type not supported: " + ca.getName() + " -- did you mean to 'enableCheckWithArbitraryClasses'?");
+                }


I think the intention to let the user double check is good. I'm not sure though if the user is really aware of the potential slow down without diving deeper into the implementation. All they know is that checkEQ somehow does not support their some objects but there is a simple workaround to still use it. So, the real question is: How many users will then consider doing something different when facing this exception and not just enable it anyway? I guess enabling is probably the most natural thing to do.

Given that, I would probably just drop this. It would also simplify the API usage in the following way:

We would only have checks with NaNs being all equals and comparing raw bits (i.e. NaNs not equal). Then you could offer checkEQ() (default) and checkRawBitsEQ() or something like that. Then users do not need to worry about creating and passing in an Options.

What do you think about these suggestions?

What we could do either way at the checkEQ() API method: Describe the potential slow down with reflection when not using certain classes.

eme64 · 2025-04-02T12:14:05Z

@chhagedorn Ok, I refactored it. I'm now always comparing arbitrary classes. And checkEQWithRawBits does the comparison with raw bits, no Options required any more. Added a comment about reflection making things slow.

chhagedorn

Thanks for the update! It's much easier to use and understand now I think.

I did a complete pass and left a lot of comments but mostly minor things. Overall, I think this looks great! :-)

test/hotspot/jtreg/compiler/lib/verify/Verify.java

chhagedorn · 2025-04-02T14:01:52Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

+    private final HashMap<Object, Object> a2b = new HashMap<>();
+    private final HashMap<Object, Object> b2a = new HashMap<>();


Can you add a comment here what a2b and b2a means? See also some other comment further down about a2b/b2a, maybe you can share some docs or cross reference.

I added some documentation :)

test/hotspot/jtreg/compiler/lib/verify/Verify.java

chhagedorn · 2025-04-02T14:48:29Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

+
+    private void print(Object a, Object b, String field, Object aParent, Object bParent) {
+        System.err.println("  aParent: " + aParent);
+        System.err.println("  bParent: " + bParent);


Should we print null parents or just skip them?

I think it does not hurt to print null here. It makes the code a little simpler.

Okay, maybe we can print <none> in case of a null for more clarity?

test/hotspot/jtreg/compiler/lib/verify/Verify.java

chhagedorn · 2025-04-02T14:51:59Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

+        Object bPrevious = a2b.get(a);
+        Object aPrevious = b2a.get(b);
+        if (aPrevious == null && bPrevious == null) {
+            // Record for next time.


Can you explain, maybe as comment at checkAlreadyVisited(), why we want to have these caches?

Added documentation :)

chhagedorn · 2025-04-02T14:52:46Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

+    private void printMemorySegmentValue(MemorySegment a, long offset, int range) {
        long start = Long.max(offset - range, 0);
        long end   = Long.min(offset + range, a.byteSize());
        for (long i = start; i < end; i++) {


Nit below: You can replace System.err.println("") with System.err.println().

test/hotspot/jtreg/testlibrary_tests/verify/examples/TestWithVectorAPI.java

Co-authored-by: Christian Hagedorn <[email protected]>

eme64 · 2025-04-03T06:19:09Z

@chhagedorn Thanks for the thorough review :)
I think I addressed all your comments 😊

chhagedorn

Thanks for addressing all my comments and doing the updates! I have some more final comments but then I think it's good to go from my side!

test/hotspot/jtreg/compiler/lib/verify/Verify.java

chhagedorn · 2025-04-03T07:28:50Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

+    private void checkEQimpl(char a, char b, String field, Object aParent, Object bParent) {
        if (a != b) {
-            System.err.println("ERROR: Verify.checkEQ failed: value mismatch: " + (int)a + " vs " + (int)b + " for " + context);
+            System.err.println("ERROR: Verify.checkEQ failed: value mismatch: " + (int)a + " vs " + (int)b);


Right, that makes sense for the char case. But good that we could remove it for the short case.

chhagedorn · 2025-04-03T07:34:44Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

+     */
+    private void checkEQimpl(float a, float b, String field, Object aParent, Object bParent) {
+        if (isFloatEQ(a, b)) {
+            System.err.println("ERROR: Verify.checkEQ failed: value mismatch. check raw: " + isFloatCheckWithRawBits);


Hm, it could indeed be a little bit more complicated when you are deep down in a recursion. My thought was that it could be misleading when a test is using a mix of verifyEQ() and verifyEQWithRawBits() and you only read verifyEQ failed. You could be start looking at the wrong check even though the stack trace would have guided you to the correct place. Maybe we can just update "Verify.checkEQ" into something more generic like "Equality matching failed" and we're good. What do you think?

chhagedorn · 2025-04-03T07:37:51Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

+        if (isFloatEQ(a, b)) {
+            System.err.println("ERROR: Verify.checkEQ failed: value mismatch. check raw: " + isFloatCheckWithRawBits);
+            System.err.println("  Values: " + a + " vs " + b);
+            System.err.println("  Raw:    " + Float.floatToRawIntBits(a) + " vs " + Float.floatToRawIntBits(b));


Sounds good, let's leave it in then!

test/hotspot/jtreg/compiler/lib/verify/Verify.java

chhagedorn · 2025-04-03T07:47:20Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

+    /**
+     * We do not want to import jdk.incubator.vector explicitly, because it would mean we would also have
+     * to add "--add-modules=jdk.incubator.vector" to the command-line of every test that uses the Verify
+     * class. So we hack this via reflection.
+     */


I think this background is only needed at checkEQForVectorAPIClass() (where you already have that comment). Here you can just describe what the code actually does or just drop the comment entirely since the method name is self-explanatory :-)

chhagedorn · 2025-04-03T07:48:30Z

test/hotspot/jtreg/compiler/lib/verify/Verify.java

+
+    private void print(Object a, Object b, String field, Object aParent, Object bParent) {
+        System.err.println("  aParent: " + aParent);
+        System.err.println("  bParent: " + bParent);


Okay, maybe we can print <none> in case of a null for more clarity?

test/hotspot/jtreg/compiler/lib/verify/Verify.java

Co-authored-by: Christian Hagedorn <[email protected]>

eme64 · 2025-04-03T08:12:22Z

@chhagedorn Thanks for having another look! I applied all your suggestions :)

chhagedorn

That looks good to me, thanks for bearing with me!

eme64 · 2025-04-04T06:15:45Z

@galderz do you intend to review / approve this, or should I ask someone else?

test/hotspot/jtreg/testlibrary_tests/verify/tests/TestVerify.java

test/hotspot/jtreg/compiler/lib/verify/Verify.java

Co-authored-by: Andrey Turbanov <[email protected]>

eme64 · 2025-04-07T06:04:35Z

@turbanoff Thanks for the two whitespace fixes :)

galderz · 2025-04-08T16:22:17Z

@eme64 No, I don't think my review counts that much on this one. I think you need someone to review it that is has more background on the history of this.

eme64 · 2025-04-30T14:11:30Z

@galderz Christian already reviewed it, and generally it is ok for someone with deeper knowledge and someone with a little less familiarity to review. So far, on Verify.java the only other commit is #22715, so there is not too much history ;)

But totally up to you, I'm thankful for the comments you already left, and they do not obligate to do a complete review :)

TobiHartmann

Looks good to me! I just found a few minor typos.

test/hotspot/jtreg/compiler/lib/verify/Verify.java

Co-authored-by: Tobias Hartmann <[email protected]>

eme64 · 2025-05-06T06:19:08Z

@chhagedorn @TobiHartmann Thanks for the reviews :)

/integrate

openjdk · 2025-05-06T06:19:58Z

@eme64 This pull request has not yet been marked as ready for integration.

eme64 · 2025-05-06T06:25:10Z

@chhagedorn Thanks!

/integrate

openjdk · 2025-05-06T06:26:12Z

Going to push as commit 9f8fbf2.
Since your change was applied there have been 14 commits pushed to the master branch:

e09d2e2: 8288471: java/awt/ScrollPane/bug8077409Test.java is unstable and fails intermittently in CI
64b58f6: 8356089: java/lang/IO/IO.java fails with -XX:+AOTClassLinking
7f6ea27: 8356020: Failed assert in virtualMemoryTracker.cpp
... and 11 more: https://git.openjdk.org/jdk/compare/1501a5e41e59162a374cf5b8cfc37faced48a6ed...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-05-06T06:26:18Z

@eme64 Pushed as commit 9f8fbf2.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

JDK-8352869

d77e5b8

clean up test

3457af0

openjdk bot changed the title ~~JDK-8352869~~ 8352869: Verify.checkEQ: extension for NaN, VectorAPI and arbitrary Objects Mar 25, 2025

openjdk bot added the hotspot-compiler [email protected] label Mar 25, 2025

eme64 marked this pull request as ready for review March 25, 2025 11:22

openjdk bot added the rfr Pull request is ready for review label Mar 25, 2025

galderz suggested changes Mar 28, 2025

View reviewed changes

eme64 and others added 3 commits March 28, 2025 09:40

Merge branch 'master' into JDK-8352869-Verify-NaN-Vector-Objects

55e7771

Update test/hotspot/jtreg/compiler/lib/verify/Verify.java

00115d4

Co-authored-by: Galder Zamarreño <[email protected]>

Verify.Options refactor for Galder

f2ed085

Merge branch 'master' into JDK-8352869-Verify-NaN-Vector-Objects

d46c45d

galderz suggested changes Mar 31, 2025

View reviewed changes

chhagedorn reviewed Mar 31, 2025

View reviewed changes

eme64 and others added 2 commits April 1, 2025 06:57

Apply suggestions from code review

30eb0e8

Co-authored-by: Christian Hagedorn <[email protected]>

upate copyright

4ca4269

chhagedorn reviewed Apr 1, 2025

View reviewed changes

eme64 mentioned this pull request Apr 2, 2025

8349138: Optimize Math.copySign API for Intel e-core targets #23386

Closed

3 tasks

refactor with checkEQWithRawBits

f2b3c37

chhagedorn reviewed Apr 2, 2025

View reviewed changes

Apply suggestions from code review

8c3e9b9

Co-authored-by: Christian Hagedorn <[email protected]>

openjdk bot removed the rfr Pull request is ready for review label Apr 3, 2025

Updates for Christian

a07f201

chhagedorn reviewed Apr 3, 2025

View reviewed changes

eme64 and others added 2 commits April 3, 2025 08:06

Apply suggestions from code review

ccb8c4b

Co-authored-by: Christian Hagedorn <[email protected]>

For Christian

b8fad69

chhagedorn approved these changes Apr 3, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Apr 3, 2025

turbanoff reviewed Apr 5, 2025

View reviewed changes

test/hotspot/jtreg/testlibrary_tests/verify/tests/TestVerify.java Outdated Show resolved Hide resolved

turbanoff reviewed Apr 5, 2025

View reviewed changes

test/hotspot/jtreg/compiler/lib/verify/Verify.java Outdated Show resolved Hide resolved

Apply suggestions from code review

49f6789

Co-authored-by: Andrey Turbanov <[email protected]>

openjdk bot removed the ready Pull request is ready to be integrated label Apr 7, 2025

TobiHartmann approved these changes May 5, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label May 5, 2025

Apply Tobias' review suggestions

187aa54

Co-authored-by: Tobias Hartmann <[email protected]>

openjdk bot removed the ready Pull request is ready to be integrated label May 5, 2025

Merge branch 'master' into JDK-8352869-Verify-NaN-Vector-Objects

23a2238

chhagedorn approved these changes May 6, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label May 6, 2025

openjdk bot added the integrated Pull request has been integrated label May 6, 2025

openjdk bot closed this May 6, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 6, 2025

-            System.err.println("ERROR: Verify.checkEQ failed: value mismatch. check raw: " + verifyOptions.isFloatCheckWithRawBits);
+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));

		private final HashMap<Object, Object> a2b = new HashMap<>();
		private final HashMap<Object, Object> b2a = new HashMap<>();

8352869: Verify.checkEQ: extension for NaN, VectorAPI and arbitrary Objects #24224

8352869: Verify.checkEQ: extension for NaN, VectorAPI and arbitrary Objects #24224

Uh oh!

Conversation

eme64 commented Mar 25, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Mar 25, 2025

Uh oh!

openjdk bot commented Mar 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Mar 25, 2025

Uh oh!

mlbridge bot commented Mar 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eme64 commented Mar 28, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chhagedorn left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eme64 commented Apr 1, 2025

Uh oh!

chhagedorn left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eme64 commented Apr 2, 2025

Uh oh!

chhagedorn left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

chhagedorn Apr 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

eme64 commented Mar 25, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Mar 25, 2025 •

edited

Loading

mlbridge bot commented Mar 25, 2025 •

edited

Loading

chhagedorn left a comment •

edited

Loading

chhagedorn left a comment •

edited

Loading

chhagedorn Apr 2, 2025 •

edited

Loading