JDK-8316708: Augment WorstCaseTests with more cases #15879

jddarcy · 2023-09-22T05:36:02Z

A new paper

"Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
https://members.loria.fr/PZimmermann/papers/accuracy.pdf

details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.

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-8316708: Augment WorstCaseTests with more cases (Enhancement - P4)

Reviewers

Raffaello Giulietti (@rgiulietti - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 15879

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

Using diff file

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

Webrev

Link to Webrev Comment

bridgekeeper · 2023-09-22T05:37:14Z

👋 Welcome back darcy! 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.

jddarcy · 2023-09-22T05:37:17Z

Since the error bars for sinh and cosh are larger, I didn't include those cases. FDLIBM pow has a bug where the actual error is outside of the spec'ed error bounds so that case is that included in this update.

openjdk · 2023-09-22T05:38:22Z

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

core-libs

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 · 2023-09-22T05:42:23Z

Webrevs

rgiulietti · 2023-09-22T15:27:51Z

test/jdk/java/lang/Math/WorstCaseTests.java

@@ -296,6 +320,9 @@ private static int testWorstTan() {
            {+0x1.D696BFA988DB9p-2,     +0x1.FAC71CD34EEA6p-2},
            {+0x1.46AC372243536p-1,     +0x1.7BA49F739829Ep-1},
            {+0x0.A3561B9121A9Bp+0,     +0x0.BDD24FB9CC14Fp+0},
+
+            // Worst-case observed error
+            {0x1.3f9605aaeb51bp+21,     -0x1.9678ee5d64935p-1},


The given expected value seems to contradict the introductory comment.
The exact value y meets -0x1.9678ee5d64935p-1 < y < -0x1.9678ee5d64934p-1, and is closer to -0x1.9678ee5d64935p-1.
Thus, the rounded value of y is -0x1.9678ee5d64935p-1, but its truncated value is -0x1.9678ee5d64934p-1.
This should be the expected value, but then the test fails.

I don't think that the test logic can support errors > 1 ulp, as is the case here.
Perhaps, rather than a single expected value, there should be explicit lower and upper bounds.

For FDLIBM tan, the stated error in the Math.tan spec is 1 ulp and the FDLIBM sources say tan is "nearly rounded," which could reasonably be interpreted as meaning within 1 ulp. However, the reported error by the paper is 1.02 ulps.

As you note here, the current testing methodology can only really deal with at most a 1 ulp error, assuming the expected value is at the lower endpoint of the range.

To avoid any lurking errors in the FDLIBM port to Java, I generated the expected numbers running jshell on JDK 20, which uses the mostly C-based FDLIBM. For a number of cases I had to decrement the expected value for the test to pass against Math and StrictMath. The decremented value and its successor may or may not bracket the exact value; I didn't verify that.

In other words, there may be other bugs in one or both math libraries the test is detecting.

So far, I've only tried running the test locally, but this would need a cross-platform run being before pushed to cover all the intrinsics that may be in use on the full set of supported platforms.

For FDLIBM tan, the stated error in the Math.tan spec is 1 ulp and the FDLIBM sources say tan is "nearly rounded," which could reasonably be interpreted as meaning within 1 ulp. However, the reported error by the paper is 1.02 ulps.

As you note here, the current testing methodology can only really deal with at most a 1 ulp error, assuming the expected value is at the lower endpoint of the range.

To avoid any lurking errors in the FDLIBM port to Java, I generated the expected numbers running jshell on JDK 20, which uses the mostly C-based FDLIBM. For a number of cases I had to decrement the expected value for the test to pass against Math and StrictMath. The decremented value and its successor may or may not bracket the exact value; I didn't verify that.

In other words, there may be other bugs in one or both math libraries the test is detecting.

So far, I've only tried running the test locally, but this would need a cross-platform run being before pushed to cover all the intrinsics that may be in use on the full set of supported platforms.

Subsequently, the allowable error bound for tan was bumped up to 1.25 ulps to cover the observed 1.02 ulp error under JDK-8326530: Widen allowable error bound of Math.tan.

rgiulietti · 2023-09-22T15:28:20Z

test/jdk/java/lang/Math/WorstCaseTests.java

@@ -52,6 +52,12 @@
 * JDK implementation complies with a 1 ulp bound on the worst-case
 * values.  Therefore, no addition leeway is afforded when testing
 * sinh and cosh.
+ *
+ * Additional worst-case observed error inputs for the FDLIBM-dervied


Suggested change

* Additional worst-case observed error inputs for the FDLIBM-dervied

* Additional worst-case observed error inputs for the FDLIBM-derived

test/jdk/java/lang/Math/WorstCaseTests.java

rgiulietti · 2023-09-22T15:48:26Z

test/jdk/java/lang/Math/WorstCaseTests.java

@@ -243,6 +261,9 @@ private static int testWorstCos() {
            {+0x1.7CB7648526F99p-1,     +0x1.78DAF01036D0Cp-1},
            {+0x1.C65A170474549p-1,     +0x1.434A3645BE208p-1},
            {+0x1.6B8A6273D7C21p+0,     +0x1.337FC5B072C52p-3},
+
+            // Worst-case observed error
+            {-0x1.34e729fd08086p+21,    +0x1.6a6a0d6a17f0fp-1},


Both Math.cos and StrictMath.cos produce the correctly rounded result here.
I don't know why the paper says otherwise. Perhaps OpenLibm is not exactly fdlibm.

Both Math.cos and StrictMath.cos produce the correctly rounded result here. I don't know why the paper says otherwise. Perhaps OpenLibm is not exactly fdlibm.

I've looked a bit over the OpenLibm changelog. They've added a few special cases for exp and pow as least. OpenLibm itself is a direct derivative of one of the BSD math libraries, which in turn was derived from FDLIBM.

Both Math.cos and StrictMath.cos produce the correctly rounded result here. I don't know why the paper says otherwise. Perhaps OpenLibm is not exactly fdlibm.

I've looked a bit over the OpenLibm changelog. They've added a few special cases for exp and pow as least. OpenLibm itself is a direct derivative of one of the BSD math libraries, which in turn was derived from FDLIBM.

The BSDs look to have changed/improved the kernel cos computation in their fork.

bridgekeeper · 2023-10-20T22:41:18Z

@jddarcy This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

jddarcy · 2023-10-20T23:30:23Z

Keep alive.

bridgekeeper · 2023-11-18T06:36:17Z

@jddarcy This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

jddarcy · 2023-12-08T06:08:33Z

Still keep alive.

bridgekeeper · 2024-01-05T12:37:32Z

@jddarcy This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

bridgekeeper · 2024-02-02T14:15:01Z

@jddarcy This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

rgiulietti · 2024-02-02T14:45:06Z

ping...

rgiulietti · 2024-02-02T14:46:07Z

/open

openjdk · 2024-02-02T14:46:16Z

@rgiulietti Only the pull request author can set the pull request state to "open"

jddarcy · 2024-02-02T17:22:03Z

/open

openjdk · 2024-02-02T17:22:09Z

@jddarcy This pull request is now open

jddarcy · 2024-02-23T19:48:07Z

Upon further reflection, I think it is worthwhile to include the worst-case tests from the more of the other math library implementations to better test potential intrinsifications of the various methods.

…g fingerprint values.

jddarcy · 2024-02-26T06:43:43Z

To improve the "fingerprinting" coverage of the StrictMath tests, I've added test cases where the worst-case of a non-FDLIBM library is larger than the FDLIBM worst-case. Assuming reasonable methodology of the paper, the output of the other math library must differ from FDLIBM at such a point.

jddarcy · 2024-02-26T06:47:30Z

To improve the "fingerprinting" coverage of the StrictMath tests, I've added test cases where the worst-case of a non-FDLIBM library is larger than the FDLIBM worst-case. Assuming reasonable methodology of the paper, the output of the other math library must differ from FDLIBM at such a point.

In a subsequent push, I'll fill those in for the functions not already so updated (cbrt, expm1, log10, log1p, etc.)

rgiulietti · 2024-02-27T11:20:01Z

test/jdk/java/lang/StrictMath/HypotTests.java

+
+            // Empirical worst-case points in other libraries with
+            // larger worst-case errors than FDLIBM
+            {0x0.00000000039a2p-1022, 0x0.0000000000001p-1022, 0x0.00000000039a2p-1022},


I can't find this one on the paper.

Suggested change

{0x0.00000000039a2p-1022, 0x0.0000000000001p-1022, 0x0.00000000039a2p-1022},

{-0x0.fffffffffffffp-1022, 0x0.0000000000001p-1022, 0x0.fffffffffffffp-1022},

I can't find this one on the paper.

Good catch; must have been a cut and paste error on my part.

rgiulietti · 2024-02-27T11:20:07Z

test/jdk/java/lang/StrictMath/Log1pTests.java

+            {-0x1.2bf32aaf122e2p-2,     -0x1.62ee0a3a4baf9p-2},
+            {-0x1.8000000000000p-53,    -0x1.8000000000001p-53},
+            {-0x1.2e496d25897ecp-2,     -0x1.663d81cb08f56p-2},
+            {-0x1.ffffffbaefe27p-2,     -0x1.62e42faa93817p-1},
        };


I think there's another case

Suggested change

};

{-0x1.5efad5491a79bp-1022, -0x1.5efad5491a79bp-1022},

};

rgiulietti · 2024-02-27T11:20:11Z

test/jdk/java/lang/StrictMath/LogTests.java

+            // Empirical worst-case points
+            {0x1.0ffea3878db6bp+0,   0x1.f07a0cca521fp-5},
+            {0x1.490af72a25a81p-1,  -0x1.c4bf7ae48f078p-2},
+            {0x1.69e7aa6da2df5p-1,  -0x1.634508c9adfp-2},


There are no libraries that have worse errors than OpenLibm, so I'm wondering what these values are good for?

There are no libraries that have worse errors than OpenLibm, so I'm wondering what these values are good for?

When I was working on updating the worst-case tests for Math, I would check the input values in Math.foo() and StrictMath.foo() and if they differed pick the smaller one as the reference value. The those inputs that differ, the input is a fingerprint marker for FDLIBM and I added cases to the corresponding StrictMath test.

rgiulietti · 2024-02-27T11:20:14Z

test/jdk/java/lang/StrictMath/TrigTests.java

+            {-0x1.f8b791cafcdefp+4,  -0x1.073ca87470dfap-3},
+            {-0x1.0e16eb809a35dp+944, 0x1.b5e361ed01dadp-2},
+            {-0x1.842d8ec8f752fp+21, -0x1.6ce864edeaffep-1},
+            {-0x1.1c49ad613ff3bp+19, -0x1.fffe203cfabe1p-2},


Some of these cases are for libraries that have better worst case errors than OpenLibm.
Are they needed here?

jddarcy · 2024-02-28T18:56:48Z

Using high-precision results from http://www.apfloat.org/calculator/, bounds in the worst-case test adjusted to the bracketing floating-point value closer to zero. Updated tests run successfully on Oracle cross-platform build and test system.

rgiulietti · 2024-03-01T14:33:42Z

Tests.java L:111 should read

     * @param d floating-point number whose exponent is to be extracted

rgiulietti · 2024-03-01T16:34:51Z

test/jdk/java/lang/Math/WorstCaseTests.java

- * Use "Table Maker's Dilemma" results from Jean-Michel Muller and
- * Vincent Lef&egrave;vre, to test the math library.  See
- * http://perso.ens-lyon.fr/jean-michel.muller/TMD.html for original
+ * This test containst two distinct kinds of worst-case inputs:


Suggested change

* This test containst two distinct kinds of worst-case inputs:

* This test contains two distinct kinds of worst-case inputs:

rgiulietti · 2024-03-01T16:34:55Z

test/jdk/java/lang/Math/WorstCaseTests.java

+ *
+ * 1) Exact numerical results that are nearly half-way between
+ * representable numbers or very close to a representable
+ * number. (Half-way caess are hardest for round to nearest even;


Suggested change

* number. (Half-way caess are hardest for round to nearest even;

* number. (Half-way cases are hardest for round to nearest even;

rgiulietti · 2024-03-01T16:34:57Z

test/jdk/java/lang/Math/WorstCaseTests.java

+ * close to a representable number cases are hard for directed
+ * roundings.)
+ *
+ * 2) Worst-case errors as observed emprically across different


Suggested change

* 2) Worst-case errors as observed emprically across different

* 2) Worst-case errors as observed empirically across different

rgiulietti · 2024-03-01T16:35:00Z

test/jdk/java/lang/Math/WorstCaseTests.java

+ * 2) Worst-case errors as observed emprically across different
+ * implementations that are not correctly rounded.
+ *
+ * For the first categpory, the "Table Maker's Dilemma" results from


Suggested change

* For the first categpory, the "Table Maker's Dilemma" results from

* For the first category, the "Table Maker's Dilemma" results from

rgiulietti · 2024-03-01T16:35:09Z

test/jdk/java/lang/Math/WorstCaseTests.java

+ *
+ * For the first categpory, the "Table Maker's Dilemma" results from
+ * Jean-Michel Muller and Vincent Lef&egrave;vre, are used.
+ * See http://perso.ens-lyon.fr/jean-michel.muller/TMD.html for original


Suggested change

* See http://perso.ens-lyon.fr/jean-michel.muller/TMD.html for original

* See https://perso.ens-lyon.fr/jean-michel.muller/TMD.html for original

rgiulietti · 2024-03-01T16:35:12Z

test/jdk/java/lang/Math/WorstCaseTests.java

+ *
+ * For the first categpory, the "Table Maker's Dilemma" results from
+ * Jean-Michel Muller and Vincent Lef&egrave;vre, are used.
+ * See http://perso.ens-lyon.fr/jean-michel.muller/TMD.html for original
 * test vectors from 2000 and see
 * http://perso.ens-lyon.fr/jean-michel.muller/TMDworstcases.pdf with


Suggested change

* http://perso.ens-lyon.fr/jean-michel.muller/TMDworstcases.pdf with

* https://perso.ens-lyon.fr/jean-michel.muller/TMDworstcases.pdf with

rgiulietti · 2024-03-01T16:35:20Z

test/jdk/java/lang/Math/WorstCaseTests.java

+            {-0x1.85e624577c23ep-1,     -0x1.614ac15b6df5ap-1},
+            {-0x1.842d8ec8f752fp+21,    -0x1.6ce864edeaffdp-1},
+            {-0x1.07e4c92b5349dp+4,     +0x1.6a096375ffb23p-1},
+            // {-0x1.13a5ccd87c9bbp+1008,  -0x1.27b3964185d8dp-1}, // check -- need +/-


High-precision computations confirm -0x1.27b3964185d8dp-1

openjdk · 2024-03-01T18:05:12Z

@jddarcy 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:

8316708: Augment WorstCaseTests with more cases

Reviewed-by: rgiulietti

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 41 new commits pushed to the master branch:

b38a6c5: 8327049: Only export debug.cpp functions on Windows
acc0a74: 8327126: Parallel: Remove unused ParMarkBitMapClosure::_initial_words_remaining
012411a: 8327046: (fs) Files.walk should be clear that depth-first traversal is pre-order
98434d6: 8322170: Update deprecated/obsolete/expired flags table for GC
c02e7f4: 8327058: RISC-V: make Zcb experimental
b972997: 8326974: ODR violation in macroAssembler_aarch64.cpp
437cf35: 8319648: java/lang/SecurityManager tests ignore vm flags
e85265a: 8325361: Make sun.net.www.MessageHeader final
5b75199: 8327022: Parallel: Remove experimental dense prefix calculation
a065eba: 8326496: [test] checkHsErrFileContent support printing hserr in error case
... and 31 more: https://git.openjdk.org/jdk/compare/4dd6c44cbdb0b5957414fa87b6c559fa4d6f2fa8...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.

jddarcy · 2024-03-01T19:29:47Z

/integrate

openjdk · 2024-03-01T19:30:36Z

Going to push as commit 7f02f07.
Since your change was applied there have been 42 commits pushed to the master branch:

8f0fb27: 8327136: javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java fails on libgraal
b38a6c5: 8327049: Only export debug.cpp functions on Windows
acc0a74: 8327126: Parallel: Remove unused ParMarkBitMapClosure::_initial_words_remaining
012411a: 8327046: (fs) Files.walk should be clear that depth-first traversal is pre-order
98434d6: 8322170: Update deprecated/obsolete/expired flags table for GC
c02e7f4: 8327058: RISC-V: make Zcb experimental
b972997: 8326974: ODR violation in macroAssembler_aarch64.cpp
437cf35: 8319648: java/lang/SecurityManager tests ignore vm flags
e85265a: 8325361: Make sun.net.www.MessageHeader final
5b75199: 8327022: Parallel: Remove experimental dense prefix calculation
... and 32 more: https://git.openjdk.org/jdk/compare/4dd6c44cbdb0b5957414fa87b6c559fa4d6f2fa8...master

Your commit was automatically rebased without conflicts.

openjdk · 2024-03-01T19:30:42Z

@jddarcy Pushed as commit 7f02f07.

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

JDK-8316708: Augment WorstCaseTests with more cases

57b112c

openjdk bot added the rfr Pull request is ready for review label Sep 22, 2023

openjdk bot added the core-libs core-libs-dev@openjdk.org label Sep 22, 2023

rgiulietti reviewed Sep 22, 2023

View reviewed changes

test/jdk/java/lang/Math/WorstCaseTests.java Outdated Show resolved Hide resolved

test/jdk/java/lang/Math/WorstCaseTests.java Outdated Show resolved Hide resolved

rgiulietti reviewed Sep 22, 2023

View reviewed changes

jddarcy added 3 commits September 22, 2023 13:48

Add stated error bounds.

3b5fc48

Fix typo found in code review.

2442b72

Merge branch 'master' into JDK-8316708

ed41690

bridgekeeper bot closed this Feb 2, 2024

openjdk bot reopened this Feb 2, 2024

Merge branch 'master' into JDK-8316708

09eb6b8

jddarcy added 2 commits February 23, 2024 12:07

Start adding worst-case inputs for other math libraries.

fb7dbb8

Improve comments, implement review feedback.

c0e9cef

jddarcy added 5 commits February 24, 2024 14:39

Add sin and asin cases.

d6830cb

Add cos test cases.

2d324a5

Checkpoint StrictMath test for trig, inverse trig, and hyperbolic tri…

d55fc49

…g fingerprint values.

Checkpoint.

bbac809

Fix missing minus sign.

ee28a7f

jddarcy added 2 commits February 26, 2024 19:48

Expand fingerprinting to more StrictMath tests.

bfe31c6

Update atan2 and hypot tests.

7b8893c

openjdk bot removed the rfr Pull request is ready for review label Feb 27, 2024

Appease jcheck.

de217d7

openjdk bot added the rfr Pull request is ready for review label Feb 27, 2024

rgiulietti reviewed Feb 27, 2024

View reviewed changes

jddarcy added 2 commits February 27, 2024 22:04

Respond to review feedback, adjust worst-case bounds.

98c8e69

Merge branch 'master' into JDK-8316708

fc8d12f

rgiulietti reviewed Mar 1, 2024

View reviewed changes

Respond to review feedback and fix typos.

e705e10

rgiulietti approved these changes Mar 1, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Mar 1, 2024

openjdk bot added the integrated Pull request has been integrated label Mar 1, 2024

openjdk bot closed this Mar 1, 2024

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Mar 1, 2024

jddarcy deleted the JDK-8316708 branch October 17, 2024 16:48

	* Additional worst-case observed error inputs for the FDLIBM-dervied
	* Additional worst-case observed error inputs for the FDLIBM-derived

	{0x0.00000000039a2p-1022, 0x0.0000000000001p-1022, 0x0.00000000039a2p-1022},
	{-0x0.fffffffffffffp-1022, 0x0.0000000000001p-1022, 0x0.fffffffffffffp-1022},

-        };
+            {-0x1.5efad5491a79bp-1022,     -0x1.5efad5491a79bp-1022},
+        };

	* This test containst two distinct kinds of worst-case inputs:
	* This test contains two distinct kinds of worst-case inputs:

	* number. (Half-way caess are hardest for round to nearest even;
	* number. (Half-way cases are hardest for round to nearest even;

	* 2) Worst-case errors as observed emprically across different
	* 2) Worst-case errors as observed empirically across different

	* For the first categpory, the "Table Maker's Dilemma" results from
	* For the first category, the "Table Maker's Dilemma" results from

	* See http://perso.ens-lyon.fr/jean-michel.muller/TMD.html for original
	* See https://perso.ens-lyon.fr/jean-michel.muller/TMD.html for original

	* http://perso.ens-lyon.fr/jean-michel.muller/TMDworstcases.pdf with
	* https://perso.ens-lyon.fr/jean-michel.muller/TMDworstcases.pdf with

JDK-8316708: Augment WorstCaseTests with more cases #15879

JDK-8316708: Augment WorstCaseTests with more cases #15879

Conversation

jddarcy commented Sep 22, 2023 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

Webrev

bridgekeeper bot commented Sep 22, 2023

jddarcy commented Sep 22, 2023

openjdk bot commented Sep 22, 2023

mlbridge bot commented Sep 22, 2023 • edited Loading

Webrevs

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jddarcy Feb 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bridgekeeper bot commented Oct 20, 2023

jddarcy commented Oct 20, 2023

bridgekeeper bot commented Nov 18, 2023

jddarcy commented Dec 8, 2023

bridgekeeper bot commented Jan 5, 2024

bridgekeeper bot commented Feb 2, 2024

rgiulietti commented Feb 2, 2024

rgiulietti commented Feb 2, 2024

openjdk bot commented Feb 2, 2024

jddarcy commented Feb 2, 2024

openjdk bot commented Feb 2, 2024

jddarcy commented Feb 23, 2024

jddarcy commented Feb 26, 2024

jddarcy commented Feb 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jddarcy commented Feb 28, 2024

rgiulietti commented Mar 1, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

openjdk bot commented Mar 1, 2024

jddarcy commented Mar 1, 2024

openjdk bot commented Mar 1, 2024

openjdk bot commented Mar 1, 2024

jddarcy commented Sep 22, 2023 •

edited by openjdk bot

Loading

mlbridge bot commented Sep 22, 2023 •

edited

Loading

jddarcy Feb 23, 2024 •

edited

Loading