8351468: C2: array fill optimization assigns wrong type to intrinsic call #24005

robcasloz · 2025-03-12T09:47:17Z

The array fill optimization replaces simple innermost loops that fill an array with copies of the same primitive value:

for (int i = 0; i < array.length; i++) {
    array[i] = 0;
}

with a call to an array filling intrinsic that is specialized for the array element type:

arrayof_jint_fill(array, 0, array.length)

The optimization retrieves the (basic) array element type from calling MemNode::memory_type() on the original filling store. This is incorrect for stores of short values, since these are represented by StoreC nodes whose memory_type() is T_CHAR. As a result, the optimization wrongly assigns the address type char[] to short array fill loops. This can cause miscompilations due to missing anti-dependences, see the issue description for further detail.

This changeset proposes retrieving the (basic) array element type from the store address type instead. This ensures that the accurate address type is assigned to the intrinsic call, preventing missed anti-dependences and other potential issues caused by mismatching types. Additionally, the changeset makes it easier to reason about correctness by explicitly disabling the optimization for mismatched stores (where the type of the value to be stored differs from the element type of the destination array). Such stores were not optimized before, but only due to pattern matching limitations.

Assuming mismatched stores are discarded (as proposed here), an alternative solution would be to define a StoreS node returning the appropriate memory_type(). This could be desirable even as a complement to this fix, to prevent similar bugs in the future. I propose to investigate the introduction of a StoreS node in a separate RFE, because it is a much larger and more intrusive changeset, and go with this minimal, local, and non-intrusive fix for backportability.

Testing: tier1-5, stress testing (linux-x64, windows-x64, macosx-x64, linux-aarch64, macosx-aarch64).

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-8351468: C2: array fill optimization assigns wrong type to intrinsic call (Bug - P3)

Reviewers

Emanuel Peter (@eme64 - Reviewer)
Tobias Hartmann (@TobiHartmann - Reviewer) Review applies to 38c9b475
Quan Anh Mai (@merykitty - Committer) Review applies to 38c9b475

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 24005

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

Using diff file

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

Using Webrev

Link to Webrev Comment

…nnacurate MemNode::memory_type()

bridgekeeper · 2025-03-12T09:48:00Z

👋 Welcome back rcastanedalo! 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-12T09:49:04Z

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

8351468: C2: array fill optimization assigns wrong type to intrinsic call

Reviewed-by: epeter, thartmann, qamai

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

a875733: 8352486: [ubsan] compilationMemoryStatistic.cpp:659:21: runtime error: index 64 out of bounds for type const struct unnamed struct
5591f8a: 8351515: C2 incorrectly removes double negation for double and float
56a4ffa: 8352597: [IR Framework] test bug: TestNotCompilable.java fails on product build
e23e0f8: 8352591: Missing UnlockDiagnosticVMOptions in VerifyGraphEdgesWithDeadCodeCheckFromSafepoints test
adfb120: 8351748: Add class init barrier to AOT-cached Method/Var Handles
ee1577b: 8352652: [BACKOUT] nsk/jvmti/ tests should fail when nsk_jvmti_setFailStatus() is called
df9210e: 8347706: jvmciEnv.cpp has jvmci includes out of order
5dd0acb: 8352477: RISC-V: Print warnings when unsupported intrinsics are enabled
334a1ee: 8351375: nsk/jvmti/ tests should fail when nsk_jvmti_setFailStatus() is called
7442039: 8337279: Share StringBuilder to format instant
... and 125 more: https://git.openjdk.org/jdk/compare/4412c079fccefbb235b22651206089f5bac47d18...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-12T09:49:36Z

@robcasloz 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.

shipilev

Wow, nice landmine.

(If you pull from current master, GHA should become clean)

mlbridge · 2025-03-12T09:58:32Z

Webrevs

merykitty · 2025-03-12T10:22:15Z

I think the issue here is the implementation of MemNode::memory_type(), it says that it returns the type of the value in memory, but it always returns T_CHAR for StoreC which seems non-sensical, what if I StoreC to a long[]?

robcasloz · 2025-03-12T14:33:15Z

I think the issue here is the implementation of MemNode::memory_type().

I agree, in particular the fact that StoreC nodes are used to represent both short and char stores but always return T_CHAR as their memory_type(). That is why I propose to simply circumvent the usage of MemNode::memory_type() to compute the type of the array fill intrinsic in this changeset, and explore creating a dedicated StoreS node in a separate RFE.

what if I StoreC to a long[]?

A store of a char value into a long[] array would be represented at the IR level as a conversion (ConvI2L) followed by a StoreL, no?

merykitty · 2025-03-12T14:43:15Z

A store of a char value into a long[] array would be represented at the IR level as a conversion (ConvI2L) followed by a StoreL, no?

No, a code such as this MemorySegment.ofArray(longArray).set(ValueLayout.JAVA_SHORT, offset, c) would produce a StoreC into a long[].

robcasloz · 2025-03-13T09:14:56Z

(If you pull from current master, GHA should become clean)

Done (commit 90fd766), thanks.

robcasloz · 2025-03-13T12:31:14Z

A store of a char value into a long[] array would be represented at the IR level as a conversion (ConvI2L) followed by a StoreL, no?

No, a code such as this MemorySegment.ofArray(longArray).set(ValueLayout.JAVA_SHORT, offset, c) would produce a StoreC into a long[].

Right, in this case I interpret from the comment at the declaration of MemNode::memory_type() that the memory_type() of the StoreC node should be T_SHORT (the type of the value stored by the node), as opposed to the current T_CHAR. I propose to address this in a separate RFE.

merykitty · 2025-03-13T15:21:17Z

@robcasloz I disagree, I would expect the memory_type of a StoreC into a long[] to be something that means "a part of a long[]", which should be T_LONG if the store is guaranteed to be enclosed in a single long, or T_VOID otherwise. While we are trying to store 2 bytes into the memory, the thing in the memory is neither a short nor a char.

galderz · 2025-03-13T17:58:26Z

... explore creating a dedicated StoreS node in a separate RFE.

Why not do this in this PR? Seems like the right approach to me.

robcasloz · 2025-03-14T09:43:24Z

... explore creating a dedicated StoreS node in a separate RFE.

Why not do this in this PR? Seems like the right approach to me.

My thinking is that this is a bug whose fix we might want to backport to several JDK Update releases. The fix proposed in this PR is minimal and local to the array fill optimization, whereas the alternative approach of defining a StoreS node (see prototype here)

is more costly to apply due to its larger changeset, and
incurs a significantly higher risk of introducing regressions, as it affects the entire C2 compilation chain (for example, I found while prototyping it that it affects the output of the store merging optimization).

See the OpenJDK Developers' Guide for a more elaborate discussion of the trade-offs involved in backporting.

Having said this, I still think we should consider introducing a StoreS node in a follow-up RFE, and perhaps also enforcing consistent type abbreviations across load and store node names, e.g. renaming LoadUSNode to LoadCNode.

robcasloz · 2025-03-14T09:54:53Z

I would expect the memory_type of a StoreC into a long[] to be something that means "a part of a long[]"

If that was the intended meaning of MemNode::memory_type(), wouldn't the function be redundant, because we can retrieve that information from MemNode::adr_type() already?

merykitty · 2025-03-14T11:51:51Z

@robcasloz Yes that's right. Then MemNode::memory_type() does not refer to the thing in memory at all, but the thing that is about to interact with the memory. I think:

We should rename it to MemNode::value_type() or MemNode::value_basic_type()
It is simply incorrect to use it to reason about the thing in the memory in this problem, and using adr_type is the correct fix.

To be clear, I don't think having StoreSNode would solve any issue. I can StoreS into a char[], and StoreC into a short[] and we are back at the same issue.

robcasloz · 2025-03-14T15:06:33Z

@robcasloz Yes that's right. Then MemNode::memory_type() does not refer to the thing in memory at all, but the thing that is about to interact with the memory.

Yes, that matches my understanding.

We should rename it to MemNode::value_type() or MemNode::value_basic_type()

I agree, it would be good to do this (in a follow-up RFE). I like MemNode::value_basic_type() best.

It is simply incorrect to use it to reason about the thing in the memory in this problem, and using adr_type is the correct fix.

To be clear, I don't think having StoreSNode would solve any issue. I can StoreS into a char[], and StoreC into a short[] and we are back at the same issue.

I agree that using adr_type() (the solution proposed in this changeset) seems more robust.

The alternative of using memory_type() and introducing a StoreS node assumes for correctness that the array fill optimization does not succeed for mismatched stores such as those you mention (e.g. StoreS into a char[]). If it did, I agree using memory_type() would be incorrect even after introducing a StoreS node. But so far, I haven't found any counterexample, i.e. any way to produce an array-filling loop with such a mismatched store that would be accepted by the array fill optimization. My attempts include using memory segments and Unsafe. In all cases, the array fill analysis in PhaseIdealLoop::match_fill_loop fails to recognize the loops due to different address computation patterns. Do you have any other idea/suggestion to trigger the array fill optimization using mismatched array stores?

robcasloz · 2025-03-17T09:44:09Z

The alternative of using memory_type() and introducing a StoreS node assumes for correctness that the array fill optimization does not succeed for mismatched stores such as those you mention (e.g. StoreS into a char[]).

After some more thought, I lean towards just disabling the OptimizeFill optimization for mismatched stores. It does not succeed today anyway due to accidental reasons (brittleness in pattern matching), so disabling it for this case should not have any other impact than making us more confident in the correctness of the optimization.

…and negative tests

robcasloz · 2025-03-18T12:40:25Z

The alternative of using memory_type() and introducing a StoreS node assumes for correctness that the array fill optimization does not succeed for mismatched stores such as those you mention (e.g. StoreS into a char[]).

After some more thought, I lean towards just disabling the OptimizeFill optimization for mismatched stores. It does not succeed today anyway due to accidental reasons (brittleness in pattern matching), so disabling it for this case should not have any other impact than making us more confident in the correctness of the optimization.

Done now, and also added a set of positive and negative test cases (commit 38c9b47) and updated the PR description. @merykitty hopefully this addresses your concerns, please let me know what you think.

eme64

@robcasloz Nice catch, I'm glad you dug this up and found a reproducer 🥳

Yes, taking the element type from the address is the best, that way you actually depend on the array, not the type of the store.

eme64 · 2025-03-20T13:35:20Z

test/hotspot/jtreg/compiler/loopopts/TestArrayFillAntiDependence.java

+ * @summary Test that loads anti-dependent on array fill intrinsics are
+ *          scheduled correctly, for different load and array fill types.
+ *          See detailed comments in testShort() below.
+ * @requires vm.compiler2.enabled


Is the test so expensive that C2 is required? Or can you just put -XX:+IgnoreUnrecognizedVMOptions in the run that has C2 flags?

eme64 · 2025-03-20T13:36:32Z

test/hotspot/jtreg/compiler/loopopts/TestArrayFillIntrinsic.java

+        // Disabling unrolling is necessary for test robustness, otherwise the
+        // compiler might decide to unroll the array-filling loop instead of
+        // replacing it with an intrinsic call even if OptimizeFill is enabled.
+        TestFramework.runWithFlags("-XX:LoopUnrollLimit=0", "-XX:+OptimizeFill");


What about a run without flags just in case?

eme64 · 2025-03-20T13:36:41Z

test/hotspot/jtreg/compiler/loopopts/TestArrayFillIntrinsic.java

+        // Disabling unrolling is necessary for test robustness, otherwise the
+        // compiler might decide to unroll the array-filling loop instead of
+        // replacing it with an intrinsic call even if OptimizeFill is enabled.
+        TestFramework.runWithFlags("-XX:LoopUnrollLimit=0", "-XX:+OptimizeFill");


What about a run without flags just in case?

TobiHartmann

Good catch and nice tests! The fix looks good to me.

merykitty

@robcasloz My concern is that MemNode::memory_type does not do what it seems to do. I wonder if there are other places misusing this method. The concern is orthogonal to this issue, though.

eme64 · 2025-03-21T09:42:16Z

@merykitty You are right, MemNode::memory_type is very easy to misunderstand. We could probably rename it, and while doing that check all usages. We have had bugs like this before, I think I had one in SuperWord as well some years ago... What would be a better name though?

Quickly looking at the cases, there are not even that many usages:

emanuel@emanuel-oracle:/oracle-work/jdk-fork0/open$ grep memory_type src/hotspot/share/opto/ -r
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const = 0;
src/hotspot/share/opto/memnode.hpp:    return type2aelembytes(memory_type(), true);
src/hotspot/share/opto/memnode.hpp:    return type2aelembytes(memory_type());
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_BYTE; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_BYTE; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_CHAR; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_SHORT; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_INT; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_LONG; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_FLOAT; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_DOUBLE; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_ADDRESS; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_NARROWOOP; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_NARROWKLASS; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_BYTE; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_CHAR; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_INT; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_LONG; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_FLOAT; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_DOUBLE; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_ADDRESS; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_NARROWOOP; }
src/hotspot/share/opto/memnode.hpp:  virtual BasicType memory_type() const { return T_NARROWKLASS; }
src/hotspot/share/opto/escape.cpp:          // StoreP::memory_type() == T_ADDRESS
src/hotspot/share/opto/escape.cpp:              store->as_Store()->memory_type() == ft) {
src/hotspot/share/opto/vectornode.hpp:  virtual BasicType memory_type() const { return T_VOID; }
src/hotspot/share/opto/vectornode.hpp:  virtual BasicType memory_type() const { return T_VOID; }
src/hotspot/share/opto/memnode.cpp:      if (memory_type() != T_VOID) {
src/hotspot/share/opto/memnode.cpp:          return phase->zerocon(memory_type());
src/hotspot/share/opto/memnode.cpp:                                                                      memory_type(), is_unsigned());
src/hotspot/share/opto/memnode.cpp:      const Type* con_type = Type::make_constant_from_field(const_oop->as_instance(), off, is_unsigned(), memory_type());
src/hotspot/share/opto/superword.cpp:      bt = n->as_Mem()->memory_type();
src/hotspot/share/opto/superword.cpp:        bt = n->as_Mem()->memory_type();
src/hotspot/share/opto/superword.cpp:        is_java_primitive(mem->memory_type())) {
src/hotspot/share/opto/superword.cpp:  if (!is_java_primitive(s1->as_Mem()->memory_type()) ||
src/hotspot/share/opto/superword.cpp:      !is_java_primitive(s2->as_Mem()->memory_type())) {
src/hotspot/share/opto/superword.cpp:    BasicType bt = n->as_Mem()->memory_type();
src/hotspot/share/opto/loopTransform.cpp:  BasicType t = store->as_Mem()->memory_type();
src/hotspot/share/opto/loopTransform.cpp:        if (type2aelembytes(store->as_Mem()->memory_type(), true) != (1 << n->in(2)->get_int())) {
src/hotspot/share/opto/loopTransform.cpp:  BasicType t = store->as_Mem()->memory_type();

Well, I looked through them, and I cannot see any issue with the other cases. But maybe someone else can give the usages a quick look too.

robcasloz · 2025-03-21T14:51:25Z

What would be a better name though?

@merykitty had the suggestions MemNode::value_type() or MemNode::value_basic_type() (see comment above), I like both better than the current name.

robcasloz · 2025-03-21T14:56:02Z

@TobiHartmann @merykitty @eme64 Thanks for reviewing! I will update the tests as suggested by @eme64 and re-run testing over the weekend.
@RealFYang I enabled the new IR tests in test/hotspot/jtreg/compiler/loopopts/TestArrayFillIntrinsic.java on riscv64 because this platform seems to handle array fill intrinsification similarly to x64 and aarch64. Would you like to test it before integration?

eme64 · 2025-03-21T15:15:00Z

What would be a better name though?

@merykitty had the suggestions MemNode::value_type() or MemNode::value_basic_type() (see comment above), I like both better than the current name.

@merykitty @robcasloz MemNode::value_basic_type() sounds like the most descriptive and accurate. Great! @robcasloz , will you file an RFE for that?

robcasloz · 2025-03-21T16:02:47Z

What would be a better name though?

@merykitty had the suggestions MemNode::value_type() or MemNode::value_basic_type() (see comment above), I like both better than the current name.

@merykitty @robcasloz MemNode::value_basic_type() sounds like the most descriptive and accurate. Great! @robcasloz , will you file an RFE for that?

Done: JDK-8352620.

RealFYang · 2025-03-22T03:10:34Z

@RealFYang I enabled the new IR tests in test/hotspot/jtreg/compiler/loopopts/TestArrayFillIntrinsic.java on riscv64 because this platform seems to handle array fill intrinsification similarly to x64 and aarch64. Would you like to test it before integration?

Hi, Thanks for the ping. Yes, both of the newly-added tests are good on linux-riscv64 platform using fastdebug build. Great!

robcasloz · 2025-03-24T08:26:08Z

Hi @eme64, I implemented your test suggestions (commit b59d2eb), please re-review.

eme64

@robcasloz Thanks for the changes!

Some thoughts about future work on intrinsic fill.

It would be nice to enable mismatched cases.
And it would be nice to enable not just arrays, but also native memory. That would be especially good for MemorySegments. But not sure how easy this change would be.

eme64 · 2025-03-24T09:31:51Z

src/hotspot/share/opto/loopTransform.cpp

+  if (msg == nullptr && store->as_Mem()->is_mismatched_access()) {
+    msg = "mismatched store";
+  }


What effect does this have?

Ah, it seems to have to do with these comments in your PR:
Additionally, the changeset makes it easier to reason about correctness by explicitly disabling the optimization for mismatched stores (where the type of the value to be stored differs from the element type of the destination array). Such stores were not optimized before, but only due to pattern matching limitations.

It may be good to leave additional comments in the code here, saying that this is a limitation, and maybe improved in the future. Up to you.

I agree, done in commit c0b3cf9.

robcasloz · 2025-03-24T10:32:25Z

Thanks for re-reviewing and the additional suggestions @eme64!

robcasloz · 2025-03-24T11:05:23Z

/integrate

openjdk · 2025-03-24T11:05:48Z

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

a875733: 8352486: [ubsan] compilationMemoryStatistic.cpp:659:21: runtime error: index 64 out of bounds for type const struct unnamed struct
5591f8a: 8351515: C2 incorrectly removes double negation for double and float
56a4ffa: 8352597: [IR Framework] test bug: TestNotCompilable.java fails on product build
e23e0f8: 8352591: Missing UnlockDiagnosticVMOptions in VerifyGraphEdgesWithDeadCodeCheckFromSafepoints test
adfb120: 8351748: Add class init barrier to AOT-cached Method/Var Handles
ee1577b: 8352652: [BACKOUT] nsk/jvmti/ tests should fail when nsk_jvmti_setFailStatus() is called
df9210e: 8347706: jvmciEnv.cpp has jvmci includes out of order
5dd0acb: 8352477: RISC-V: Print warnings when unsupported intrinsics are enabled
334a1ee: 8351375: nsk/jvmti/ tests should fail when nsk_jvmti_setFailStatus() is called
7442039: 8337279: Share StringBuilder to format instant
... and 125 more: https://git.openjdk.org/jdk/compare/4412c079fccefbb235b22651206089f5bac47d18...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-03-24T11:05:57Z

@robcasloz Pushed as commit de58009.

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

robcasloz added 4 commits March 10, 2025 16:21

Compute basic type from the store's address type, circumventing the i…

9e18e41

…nnacurate MemNode::memory_type()

Refine assertion to deal with aliasing byte/Boolean types

fd8d381

Add test

54de1cd

Remove temporary assertion

47e478a

openjdk bot added the hotspot-compiler hotspot-compiler-dev@openjdk.org label Mar 12, 2025

robcasloz marked this pull request as ready for review March 12, 2025 09:51

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

shipilev reviewed Mar 12, 2025

View reviewed changes

Merge master

90fd766

Explicitly disable optimization for mismatching stores; add positive …

38c9b47

…and negative tests

eme64 approved these changes Mar 20, 2025

View reviewed changes

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

TobiHartmann approved these changes Mar 20, 2025

View reviewed changes

merykitty approved these changes Mar 20, 2025

View reviewed changes

Relax test cases

b59d2eb

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

eme64 approved these changes Mar 24, 2025

View reviewed changes

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

Add comment about mismatched store handling

c0b3cf9

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

eme64 approved these changes Mar 24, 2025

View reviewed changes

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

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

openjdk bot closed this Mar 24, 2025

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

8351468: C2: array fill optimization assigns wrong type to intrinsic call #24005

8351468: C2: array fill optimization assigns wrong type to intrinsic call #24005

Uh oh!

Conversation

robcasloz commented Mar 12, 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 12, 2025

Uh oh!

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

Uh oh!

Uh oh!

openjdk bot commented Mar 12, 2025

Uh oh!

shipilev left a comment

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Webrevs

Uh oh!

merykitty commented Mar 12, 2025

Uh oh!

robcasloz commented Mar 12, 2025

Uh oh!

merykitty commented Mar 12, 2025

Uh oh!

robcasloz commented Mar 13, 2025

Uh oh!

robcasloz commented Mar 13, 2025

Uh oh!

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

Uh oh!

Uh oh!

galderz commented Mar 13, 2025

Uh oh!

robcasloz commented Mar 14, 2025

Uh oh!

robcasloz commented Mar 14, 2025

Uh oh!

merykitty commented Mar 14, 2025

Uh oh!

robcasloz commented Mar 14, 2025

Uh oh!

robcasloz commented Mar 17, 2025

Uh oh!

robcasloz commented Mar 18, 2025

Uh oh!

eme64 left a comment

Choose a reason for hiding this comment

Uh oh!

eme64 Mar 20, 2025

Choose a reason for hiding this comment

Uh oh!

eme64 Mar 20, 2025

Choose a reason for hiding this comment

Uh oh!

eme64 Mar 20, 2025

Choose a reason for hiding this comment

Uh oh!

TobiHartmann left a comment

Choose a reason for hiding this comment

Uh oh!

merykitty left a comment

Choose a reason for hiding this comment

Uh oh!

eme64 commented Mar 21, 2025

Uh oh!

robcasloz commented Mar 21, 2025

Uh oh!

robcasloz commented Mar 21, 2025

Uh oh!

eme64 commented Mar 21, 2025

Uh oh!

robcasloz commented Mar 21, 2025

Uh oh!

robcasloz commented Mar 12, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Mar 12, 2025 •

edited

Loading

mlbridge bot commented Mar 12, 2025 •

edited

Loading

merykitty commented Mar 13, 2025 •

edited

Loading