8349361: C2: RShiftL should support all applicable transformations that RShiftI does by rwestrel · Pull Request #23438 · openjdk/jdk

rwestrel · 2025-02-04T13:02:47Z

This change refactors RShiftI/RshiftL Ideal, Identity and
Value because the int and long versions are very similar and so
there's no logic duplication. In the process, support for some extra
transformations is added to RShiftL. I also added some new test
cases.

/cc hotspot-compiler

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-8349361: C2: RShiftL should support all applicable transformations that RShiftI does (Enhancement - P4)

Reviewers

Emanuel Peter (@eme64 - Reviewer)
Jasmine Karthikeyan (@jaskarth - Committer) Review applies to e4053783
Christian Hagedorn (@chhagedorn - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 23438

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

Using diff file

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

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-02-04T13:03:19Z

👋 Welcome back roland! 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-02-04T13:03:39Z

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

8349361: C2: RShiftL should support all applicable transformations that RShiftI does

Reviewed-by: epeter, chagedorn, jkarthikeyan

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

0cb110e: 8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields
04eac0c: 8352159: RISC-V: add more zfa support
ac760dd: 8352423: RISC-V: simplify DivI/L ModI/L
d1cf232: 8352248: Check if CMoveX is supported
2b55979: 8352529: RISC-V: enable loopopts tests
8469458: 8352511: Show additional level of headings in table of contents
28250f8: 8352151: Fix display issues in javadoc-generated docs
b32be18: 8352178: Add precondition in VMThread::execute to prevent deadlock
07667ca: 8352506: Simplify make/test/JtregNativeHotspot.gmk
b545b9e: 8352584: [Backout] G1: Pinned regions with pinned objects only reachable by native code crash VM
... and 81 more: https://git.openjdk.org/jdk/compare/4e51a8c9ad4e5345d05cf32ce1e82b7158f80e93...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-02-04T13:04:02Z

@rwestrel
The hotspot-compiler label was successfully added.

mlbridge · 2025-02-04T13:06:24Z

Webrevs

eme64

Drive-by code style comment ;)

eme64 · 2025-02-04T18:11:42Z

src/hotspot/share/opto/mulnode.cpp

-//=============================================================================
-//------------------------------Identity---------------------------------------
-Node* RShiftINode::Identity(PhaseGVN* phase) {
+Node *RShiftNode::IdealIL(PhaseGVN *phase, bool can_reshape, BasicType bt) {


Drive-by: fix position of *

eme64 · 2025-02-04T18:12:20Z

src/hotspot/share/opto/mulnode.cpp

+Node *RShiftNode::IdealIL(PhaseGVN *phase, bool can_reshape, BasicType bt) {
+  // Inputs may be TOP if they are dead.
+  const TypeInteger* t1 = phase->type(in(1))->isa_integer(bt);
+  if (!t1) return NodeSentinel;        // Left input is an integer


Drive-by: don't use implicit null-check, make comparison with nullptr explicit. And add curly braces.

TobiHartmann · 2025-02-05T06:44:47Z

Fails to build on Mac AArch64:

[2025-02-05T06:43:04,925Z] * For target hotspot_variant-server_libjvm_objs_mulnode.o:
[2025-02-05T06:43:04,925Z] [...]workspace/open/src/hotspot/share/opto/mulnode.cpp:1400:13: error: use of bitwise '&' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
[2025-02-05T06:43:04,925Z]      assert((checked_cast<jint>(lo) == lo_verify) & (checked_cast<jint>(hi) == hi_verify), "inconsistent");

rwestrel · 2025-02-05T15:38:20Z

Fails to build on Mac AArch64:

[2025-02-05T06:43:04,925Z] * For target hotspot_variant-server_libjvm_objs_mulnode.o:
[2025-02-05T06:43:04,925Z] [...]workspace/open/src/hotspot/share/opto/mulnode.cpp:1400:13: error: use of bitwise '&' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
[2025-02-05T06:43:04,925Z]      assert((checked_cast<jint>(lo) == lo_verify) & (checked_cast<jint>(hi) == hi_verify), "inconsistent");

Thanks for the report. Should be fixed now. I also took @eme64's comments into account.

jaskarth

This is really nice! I'd wondered why there was no RShiftL::Ideal, and it's nice to have it handled it in a generic way with the integer version. I left mostly code style comments here.

src/hotspot/share/opto/type.cpp

jaskarth · 2025-02-05T15:45:08Z

src/hotspot/share/utilities/globalDefinitions.hpp

+  if (bt == T_INT) {
+    return BitsPerJavaInteger;
+  }
+  return BitsPerJavaLong;


I think it'd be nice to add assert(bt == T_LONG, "unsupported"); before the last return, like in the helper methods above.

Indeed. Added in new commit.

src/hotspot/share/opto/mulnode.cpp

src/hotspot/share/opto/mulnode.hpp

jaskarth · 2025-02-05T15:58:58Z

src/hotspot/share/opto/mulnode.cpp

+    jlong hi = r1->hi_as_long() >> (jint)shift;
+    assert(lo <= hi, "must have valid bounds");
+#ifdef ASSERT
+   if (bt ==T_INT) {


Suggested change

if (bt ==T_INT) {

if (bt == T_INT) {

Could this assert be generic to also handle T_LONG too?

The assert checks that, for the int case:

long lo; assert((int)(lo >> shift) == (((int)lo) >> shift, "");

For long, it would be:

long lo; assert((long)(lo >> shift) == (((long)lo) >> shift, "");

Given everything is already a long, that's:

long lo; assert(lo >> shift == lo >> shift, "");

Ah I see, thank you for the explanation!

Co-authored-by: Jasmine Karthikeyan <25208576+jaskarth@users.noreply.github.com>

rwestrel · 2025-02-07T10:03:08Z

This is really nice! I'd wondered why there was no RShiftL::Ideal, and it's nice to have it handled it in a generic way with the integer version. I left mostly code style comments here.

Thanks for reviewing this. I pushed a new commit that takes your comments into account.

jaskarth

Thanks for the update, it looks good!

eme64

@rwestrel nice work, looks like a good step to unify the code a little!

I left some comments / suggestions.

I'm also wondering about testing. How good do you think test coverage is? Are all cases covered? How about the edge-cases? Could we improve the coverage with randomization somehow?

src/hotspot/share/opto/mulnode.cpp

eme64 · 2025-02-13T10:20:19Z

src/hotspot/share/opto/mulnode.cpp

+  if (t1 == nullptr) {
+    return NodeSentinel;        // Left input is an integer
+  }
+  const TypeInteger* t3;  // type of in(1).in(2)


I know that you only moved this code, but it looks bad 🙈
For one, why is it defined up here already when it is only used 10 lines later?
And why not give it a better name so we don't need the comment?

Suggested change

const TypeInteger* t3; // type of in(1).in(2)

eme64 · 2025-02-13T10:26:31Z

src/hotspot/share/opto/mulnode.cpp

+      (t3 = phase->type(mask->in(2))->isa_integer(bt)) &&
+      t3->is_con()) {
+    jlong maskbits = t3->get_con_as_long(bt);
+    // Convert to "(x >> shift) & (mask >> shift)"


This is a nice comment. It could come as a motivation above. Because it suggests that we can then constant fold the mask >> shift, right?

eme64 · 2025-02-13T10:26:39Z

src/hotspot/share/opto/mulnode.cpp

+  const Node* mask = in(1);
+  if (mask->Opcode() == Op_And(bt) &&
+      (t3 = phase->type(mask->in(2))->isa_integer(bt)) &&
+      t3->is_con()) {
+    jlong maskbits = t3->get_con_as_long(bt);


This is also quite bad. It seems mask here is in(1), which is not even the mask at all, but x & <real_mask>.

I'd suggest to clean it up a little and use better names.

src/hotspot/share/opto/mulnode.cpp

eme64 · 2025-02-13T10:37:52Z

src/hotspot/share/opto/mulnode.cpp

+  if (progress != nullptr) {
+    return progress;
  }
+  const TypeInt* t3;  // type of in(1).in(2)


Also refactor the use of t3 here, please.

eme64 · 2025-02-13T10:44:01Z

test/hotspot/jtreg/compiler/c2/irTests/RShiftLNodeIdealizationTests.java

    }

-    @Run(test = { "test1", "test2", "test3", "test4" })
+    @Run(test = { "test1", "test2", "test3", "test4", "test5", "test6", "test7", "test8", "test9" })


You should add the bug id above.

eme64 · 2025-02-13T10:44:56Z

test/hotspot/jtreg/compiler/c2/irTests/RShiftLNodeIdealizationTests.java

+    final int test7Shift = 42;
+    final long test7Min = -1L << (64 - test7Shift -1);
+    final long test7Max = ~test7Min;


Could we randomize these tests, so that we would get better coverage?

Co-authored-by: Emanuel Peter <emanuel.peter@oracle.com>

rwestrel · 2025-02-14T15:54:35Z

I left some comments / suggestions.

Thanks for reviewing this. I pushed new commits that I think cover your comments.

I'm also wondering about testing. How good do you think test coverage is? Are all cases covered? How about the edge-cases? Could we improve the coverage with randomization somehow?

Transformations that I refactored and now apply to both the long and int RShift should now have test cases. I tweaked the test cases so there are now randomized.

rwestrel · 2025-02-24T13:07:05Z

@eme64 can you take another look?

Co-authored-by: Emanuel Peter <emanuel.peter@oracle.com>

…Tests.java Co-authored-by: Emanuel Peter <emanuel.peter@oracle.com>

chhagedorn

Nice refactoring! I have a few small comments - mostly code style. Otherwise, looks good to me, too.

chhagedorn · 2025-03-13T08:32:27Z

src/hotspot/share/opto/mulnode.cpp

+  if (t1 == Type::TOP) return Type::TOP;
+  if (t2 == Type::TOP) return Type::TOP;

  // Left input is ZERO ==> the result is ZERO.
-  if( t1 == TypeInt::ZERO ) return TypeInt::ZERO;
+  if (t1 == TypeInteger::zero(bt)) return TypeInteger::zero(bt);
  // Shift by zero does nothing
-  if( t2 == TypeInt::ZERO ) return t1;
+  if (t2 == TypeInt::ZERO) return t1;


Can you add braces here for safety?

src/hotspot/share/opto/mulnode.cpp

chhagedorn · 2025-03-13T09:16:17Z

src/hotspot/share/opto/mulnode.cpp

-      int hi = ~lo;               // 00007FFF
-      const TypeInt* t11 = phase->type(in(1)->in(1))->isa_int();
+      jlong lo = (-1 << (bits_per_java_integer(bt) - ((uint)count)-1)); // FFFF8000
+      jlong hi = ~lo;               // 00007FFF


Seems strangely aligned. Maybe either align it to the comment above or convert to an unaligned comment.

chhagedorn · 2025-03-13T09:20:23Z

src/hotspot/share/opto/mulnode.cpp

+    if (in(1)->Opcode() == Op_LShift(bt) &&
        in(1)->req() == 3 &&
        in(1)->in(2) == in(2)) {


Generally, is there notifaction code for this pattern to re-add the node to the IGVN worklist? If not, I don't think you need to handle it here if it's missing (it's just a missed opportunity but no correctness issue) but would be good to file a follow-up bug to handle it - especially when we want to add IGVN verification for Ideal and Identity with JDK-8347273.

Good catch. I fixed a case that was handled for int but not for long. There are others that are missing for both AFAICT.
If I file a follow up bug, writing a test case for it is going to be very hard. So testing a fix is also hard. Shouldn't we wait for JDK-8347273 and fix whatever follows up of that?

If I file a follow up bug, writing a test case for it is going to be very hard

Yes, it will be. There is currently no way to really verify that reliably without the additional verification. I think it's okay to wait for JDK-8347273. Maybe you can add a note there or file a separate issue to keep track of the missing bits detected in this investigation..

src/hotspot/share/opto/mulnode.cpp

src/hotspot/share/opto/mulnode.hpp

chhagedorn · 2025-03-13T09:27:18Z

src/hotspot/share/opto/type.cpp

  return TypeLong::make(lo, hi, w);
 }

+const TypeInteger* TypeInteger::make(jlong lo, BasicType bt) {


Maybe you want to rename lo to con since we set lo == hi.

chhagedorn · 2025-03-13T09:28:45Z

test/hotspot/jtreg/compiler/c2/irTests/RShiftINodeIdealizationTests.java

@@ -27,7 +27,7 @@



Up to you if you want to update the copyright year or add your company's copyright. Same in the other test.

Co-authored-by: Christian Hagedorn <christian.hagedorn@oracle.com>

rwestrel · 2025-03-13T16:42:59Z

Nice refactoring! I have a few small comments - mostly code style. Otherwise, looks good to me, too.

Thanks for the review.
New commit should address all your comments.
Now that the long min/max intrinsic is integrated, I also changed the long tests so they use long min/max and that triggered a bug in the code (missing CONST64) that I fixed.

eme64 · 2025-03-14T07:12:53Z

@rwestrel I saw this in testing from yesterday: linux-aarch64-debug with -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders.

Failed IR Rules (2) of Methods (2)
----------------------------------
1) Method "public long compiler.c2.irTests.RShiftLNodeIdealizationTests.test8(long)" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#RSHIFT_L#_", "1", "_#LSHIFT_L#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(RShiftL.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 = 1 [given]
           - No nodes matched!
         * Constraint 2: "(\\d+(\\s){2}(LShiftL.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 = 1 [given]
           - No nodes matched!

2) Method "public long compiler.c2.irTests.RShiftLNodeIdealizationTests.test9(long)" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#RSHIFT_L#_", "1", "_#LSHIFT_L#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(RShiftL.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 = 1 [given]
           - No nodes matched!
         * Constraint 2: "(\\d+(\\s){2}(LShiftL.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 = 1 [given]
           - No nodes matched!

eme64 · 2025-03-14T07:13:59Z

Not sure if that still reproduces after your changes. LMK when I should run testing again.

chhagedorn

Apart from Emanuel's report, it looks good to me, thanks for the update!

rwestrel · 2025-03-14T09:48:26Z

Not sure if that still reproduces after your changes. LMK when I should run testing again.

I could reproduce that one by forcing one of the random values to a particular constant. It's a bug in the test that was fixed since. @eme64 could you run testing again, please?

rwestrel · 2025-03-21T13:24:46Z

@eme64 any update on testing?

eme64 · 2025-03-21T13:28:50Z

@rwestrel Testing looks good, thanks for the ping :)

eme64

Gave it a quick pass again, I think this is good to go (though better to integrate after the weekend...)

@rwestrel thanks for the work and all the updates ☺️

rwestrel · 2025-03-26T14:35:29Z

@eme64 thanks for running tests and for the review.
@chhagedorn @jaskarth thanks for the reviews.

rwestrel · 2025-03-26T14:35:38Z

/integrate

openjdk · 2025-03-26T14:37:53Z

Going to push as commit 79bffe2.
Since your change was applied there have been 162 commits pushed to the master branch:

eef6aef: 8352623: MultiExchange should cancel exchange impl if responseFilters throws
e2a461b: 8351332: Line breaks in search tag descriptions corrupt JSON search index
c14bbea: 8352740: Introduce new factory method HtmlTree.IMG
84d3dc7: 8352965: [BACKOUT] 8302459: Missing late inline cleanup causes compiler/vectorapi/VectorLogicalOpIdentityTest.java IR failure
b4dc364: 8346931: Replace divisions by zero in sharedRuntimeTrans.cpp
bc5cde1: 8352692: Add support for extra jlink options
059f190: 8352490: Fatal error message for unhandled bytecode needs more detail
ee710fe: 8345169: Implement JEP 503: Remove the 32-bit x86 Port
eb6e828: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad tests fail intermittently
e32a0c9: 8352706: httpclient HeadTest does not run on HTTP2
... and 152 more: https://git.openjdk.org/jdk/compare/4e51a8c9ad4e5345d05cf32ce1e82b7158f80e93...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-03-26T14:38:07Z

@rwestrel Pushed as commit 79bffe2.

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

fix & test

806eb20

openjdk bot added rfr Pull request is ready for review hotspot-compiler hotspot-compiler-dev@openjdk.org labels Feb 4, 2025

eme64 suggested changes Feb 4, 2025

View reviewed changes

review

a1225f7

jaskarth reviewed Feb 5, 2025

View reviewed changes

rwestrel and others added 7 commits February 7, 2025 09:44

Update src/hotspot/share/opto/type.cpp

f50d46a

Co-authored-by: Jasmine Karthikeyan <25208576+jaskarth@users.noreply.github.com>

Update src/hotspot/share/opto/mulnode.cpp

2281946

Co-authored-by: Jasmine Karthikeyan <25208576+jaskarth@users.noreply.github.com>

Update src/hotspot/share/opto/mulnode.cpp

c9b76fd

Co-authored-by: Jasmine Karthikeyan <25208576+jaskarth@users.noreply.github.com>

Update src/hotspot/share/opto/mulnode.cpp

b8f1cf6

Co-authored-by: Jasmine Karthikeyan <25208576+jaskarth@users.noreply.github.com>

Update src/hotspot/share/opto/mulnode.cpp

c43d65b

Co-authored-by: Jasmine Karthikeyan <25208576+jaskarth@users.noreply.github.com>

Update src/hotspot/share/opto/mulnode.hpp

8bac2ca

Co-authored-by: Jasmine Karthikeyan <25208576+jaskarth@users.noreply.github.com>

review

e405378

jaskarth approved these changes Feb 9, 2025

View reviewed changes

eme64 suggested changes Feb 13, 2025

View reviewed changes

rwestrel and others added 6 commits February 13, 2025 17:54

Update src/hotspot/share/opto/mulnode.cpp

bb70779

Co-authored-by: Emanuel Peter <emanuel.peter@oracle.com>

Update src/hotspot/share/opto/mulnode.cpp

0f1b76a

Co-authored-by: Emanuel Peter <emanuel.peter@oracle.com>

Merge branch 'master' into JDK-8349361

96f7fe6

review

7a101d1

review

7282176

review

5b05d22

rwestrel and others added 2 commits March 13, 2025 08:53

Update src/hotspot/share/opto/mulnode.cpp

2815699

Co-authored-by: Emanuel Peter <emanuel.peter@oracle.com>

Update test/hotspot/jtreg/compiler/c2/irTests/RShiftLNodeIdealization…

9c0b859

…Tests.java Co-authored-by: Emanuel Peter <emanuel.peter@oracle.com>

chhagedorn approved these changes Mar 13, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Mar 13, 2025

rwestrel and others added 2 commits March 13, 2025 14:56

Update src/hotspot/share/opto/mulnode.cpp

9de1088

Co-authored-by: Christian Hagedorn <christian.hagedorn@oracle.com>

Update src/hotspot/share/opto/mulnode.cpp

bff875e

Co-authored-by: Christian Hagedorn <christian.hagedorn@oracle.com>

openjdk bot removed the ready Pull request is ready to be integrated label Mar 13, 2025

rwestrel and others added 6 commits March 13, 2025 14:59

Update src/hotspot/share/opto/mulnode.cpp

52dca4d

Co-authored-by: Christian Hagedorn <christian.hagedorn@oracle.com>

Update src/hotspot/share/opto/mulnode.hpp

73b73bf

Co-authored-by: Christian Hagedorn <christian.hagedorn@oracle.com>

Update src/hotspot/share/opto/mulnode.cpp

1911ca6

Co-authored-by: Christian Hagedorn <christian.hagedorn@oracle.com>

review

a226303

Merge branch 'master' into JDK-8349361

3aa25e1

test with Long.Min/Long.Max + CONST64

a56e397

chhagedorn approved these changes Mar 14, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Mar 14, 2025

eme64 approved these changes Mar 21, 2025

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Mar 26, 2025

openjdk bot closed this Mar 26, 2025

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

Conversation

rwestrel commented Feb 4, 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 Feb 4, 2025

Uh oh!

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

Uh oh!

Uh oh!

openjdk bot commented Feb 4, 2025

Uh oh!

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

Uh oh!

Webrevs

Uh oh!

eme64 left a comment

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!

TobiHartmann commented Feb 5, 2025

Uh oh!

rwestrel commented Feb 5, 2025

Uh oh!

jaskarth left a comment

Choose a reason for hiding this comment

Uh oh!

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!

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!

rwestrel commented Feb 7, 2025

Uh oh!

jaskarth left a comment

Choose a reason for hiding this comment

Uh oh!

eme64 left a comment

Choose a reason for hiding this comment

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!

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!

rwestrel commented Feb 14, 2025

Uh oh!

rwestrel commented Feb 24, 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!

rwestrel commented Feb 4, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Feb 4, 2025 •

edited

Loading

mlbridge bot commented Feb 4, 2025 •

edited

Loading

chhagedorn Mar 13, 2025 •

edited

Loading

rwestrel commented Mar 14, 2025 •

edited

Loading