8324517: C2: crash in compiled code because of dependency on removed range check CastIIs #18377

rwestrel · 2024-03-19T13:21:49Z

Range check CastII nodes are removed once loop opts are over. The
test case for this change includes 3 cases where elimination of a
range check CastII causes a crash in compiled code because either a
out of bounds array load or a division by zero happen.

In test1:

the range checks for the array[otherArray.length] loads constant
fold: otherArray.length is a CastII of i at the otherArray
allocation. i is less than 9. The CastII at the allocation
narrows the type down further to [0-9].
the array[otherArray.length] loads are control dependent on the
unrelated:

if (flag == 0) {

test. There's an identical dominating test which replaces that one. As
a consequence, the array[otherArray.length] loads become control
dependent on the dominating test.

The CastII nodes at the otherArray allocations are replaced by a
dominating range check CastII nodes for:

newArray[i] = 42;

After loop opts, the range check CastII nodes are removed and the
2 array[otherArray.length] loads common at the first:

if (flag == 0) {

test before the:

float[] otherArray = new float[i];

and

newArray[i] = 42;

that guarantee i is positive.

test1 is called with i = -1, the array load proceeds with an out
of bounds index and the crash occurs.

test2 and test3 are mostly identical except for the check that's
eliminated (a null divisor check) and the instruction that causes a
fault (an integer division).

The fix I propose is to not eliminate range check CastII nodes after
loop opts. When range checkCastII nodes were introduced, performance
was observed to regress. Removing them after loop opts was found to
preserve both correctness and performance. Today, the performance
regression still exists when CastII nodes are left in. So I propose
we keep them until the end of optimizations (so the 2 array loads
above don't lose a dependency and wrongly common) but remove them at
the end of all optimizations.

In the case of the array loads, they are dependent on a range check
for another array through a range check CastII and we must not lose
that dependency otherwise the array loads could float above the range
check at gcm time. I propose we deal with that problem the way it's
handled for CastPP nodes: add the dependency to the load (or
division)nodes as a precedence edge when the cast is removed.

@TobiHartmann ran performance testing for that patch (Thanks!) and reported
no regression.

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-8324517: C2: crash in compiled code because of dependency on removed range check CastIIs (Bug - P3)

Reviewers

Emanuel Peter (@eme64 - Reviewer)
Tobias Hartmann (@TobiHartmann - Reviewer) ⚠️ Review applies to 5cc658b6

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 18377

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

Using diff file

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

Webrev

Link to Webrev Comment

bridgekeeper · 2024-03-19T13:22:12Z

👋 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 · 2024-03-19T13:22:54Z

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

8324517: C2: crash in compiled code because of dependency on removed range check CastIIs

Reviewed-by: epeter, 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 16 new commits pushed to the master branch:

8032d64: 8332245: C2: missing record_for_ign() call in GraphKit::must_be_not_null()
fa043ae: 8294880: Review running time of jdk/internal/shellsupport/doc/JavadocHelperTest.java
a5005c8: 8330814: Cleanups for KeepAliveCache tests
1a94447: 8332111: [BACKOUT] A way to align already compiled methods with compiler directives
957eb61: 8331429: [JVMCI] Cleanup JVMCIRuntime allocation routines
2f10a31: 8302850: Implement C1 clone intrinsic that reuses arraycopy code for primitive arrays
c642f44: 8329839: Cleanup ZPhysicalMemoryBacking trace logging
d04ac14: 8332236: javac crashes with module imports and implicitly declared class
4e77cf8: 8330795: C2: assert((uint)type <= T_CONFLICT && _zero_type[type] != nullptr) failed: bad type with -XX:-UseCompressedClassPointers
7b4ba7f: 8325932: Replace ATTRIBUTE_NORETURN with direct [[noreturn]]
... and 6 more: https://git.openjdk.org/jdk/compare/7ce4a13c0a891e606480e138f4025ffa328a18b3...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 · 2024-03-19T13:23:17Z

@rwestrel 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 · 2024-03-19T13:27:30Z

Webrevs

eme64

Thanks @rwestrel !
Generally makes sense, I have a few suggestions and questions.

eme64 · 2024-03-28T11:45:26Z

src/hotspot/share/opto/compile.cpp

+    // For memory access or integer divisions nodes that depend on the cast, record the dependency on the cast's control
+    // as a precedence edge, so they can't float above the cast in case that cast's narrowed type helped eliminated a
+    // range check or a null divisor check.
+    assert(cast->in(0) != nullptr, "");


Suggested change

assert(cast->in(0) != nullptr, "");

assert(cast->in(0) != nullptr, "All RangeCheck CastII must have a control dependency");

Done in new commit.

eme64 · 2024-03-28T11:53:02Z

src/hotspot/share/opto/castnode.cpp

-  // the corresponding range check is not removed.
-  if (!_range_check_dependency) {
-    res = widen_type(phase, res, T_INT);
-  }


Can you explain why you changed this, and why it is ok?

ConvI2L has a similar transformation. Let's say we have 2 ConvI2L nodes with identical inputs but different types:

(ConvI2L _ input [2..max_jint]) (ConvI2L _ input [1..max_jint])

They are transformed to:

(ConvI2L _ input [0..max_jint]) (ConvI2L _ input [0..max_jint])

so they can common. With range checks, the pattern is:

(ConvI2L _ (CastII control input [2..max_jint]) [2..max_jint]) (ConvI2L _ (CastII control input [1..max_jint]) [1..max_jint]

Without this patch, the range checks CastII are removed after loop opts so having the transformation be done only on ConvI2L nodes is sufficient. With this change the CastII are left in the IR so they need to be transformed the same way:

(ConvI2L _ (CastII control input [0..max_jint]) [0..max_jint]) (ConvI2L _ (CastII control input [0..max_jint]) [0..max_jint]

so they can common and the ConvI2L then common.

eme64 · 2024-03-28T11:53:18Z

src/hotspot/share/opto/castnode.cpp

    // makes sure we run ::Value to potentially remove type assertion after loop opts
    phase->C->record_for_post_loop_opts_igvn(this);
  }
-  if (!_range_check_dependency) {
+  if (!_type->is_int()->empty()) {


Can you also explain this change, please?

It's similar to the case above. ConvI2L has a similar transformation (Add node pushed through ConvI2L). For range checks, the CastII gets in the way but it wasn't an issue without the patch I propose (the CastII ends up going away). Leaving the CastII requires that the transformation happens on the CastII as well. The:

!_type->is_int()->empty()

test doesn't replace the

!_range_check_dependency

I removed the second one, ran some testing and then had a failure where the ConstraintCastNode::optimize_integer_cast() crashes because it gets called with an empty type so I added the test for an empty type. I don't remember the details of the failure other than it seemed like a corner case.

eme64 · 2024-03-28T11:54:47Z

test/hotspot/jtreg/compiler/rangechecks/TestArrayAccessAboveRCAfterRCCastIIEliminated.java

+ *                   -XX:CompileCommand=dontinline,TestArrayAccessAboveRCAfterRCCastIIEliminated::notInlined
+ *                   -XX:+StressIGVN -XX:StressSeed=94546681 TestArrayAccessAboveRCAfterRCCastIIEliminated
+ *
+ */


Can you please add a "vanilla" run like this:
@run main TestArrayAccessAboveRCAfterRCCastIIEliminated
That would allow us to run the test with any flag combination from the outside.

And maybe one that only does -XX:CompileCommand=dontinline,TestArrayAccessAboveRCAfterRCCastIIEliminated::notInlined, since that seems important for reproducing the interesting patterns.

Done in new commit.

eme64 · 2024-03-28T11:55:06Z

test/hotspot/jtreg/compiler/rangechecks/TestArrayAccessAboveRCAfterRCCastIIEliminated.java

+ *
+ */
+
+public class TestArrayAccessAboveRCAfterRCCastIIEliminated {


It seems this test is not in a package. Is this on purpose?

Not sure if that is important, but it seems most other tests are in a package

I never put tests in a package. So If there's an issue with that, then there are many more tests to fix.

Fine with me. I was just curious, and have mostly seen tests that are in a package.

rwestrel · 2024-03-28T14:12:05Z

Thanks @rwestrel ! Generally makes sense, I have a few suggestions and questions.

Thanks for reviewing this.

rwestrel · 2024-04-05T12:48:35Z

@eme64 did you get a chance to look at the answers to your questions?

eme64 · 2024-04-05T13:11:38Z

@rwestrel It seems I only get notifications for new messages, not responses. Looking at the PR now...

eme64

Thanks for the updates and answers, @rwestrel !
Looks reasonable, a second reviewer should also have a close look though.

eme64 · 2024-04-05T13:14:52Z

test/hotspot/jtreg/compiler/rangechecks/TestArrayAccessAboveRCAfterRCCastIIEliminated.java

+ * @run main/othervm -XX:-TieredCompilation -XX:-UseOnStackReplacement -XX:-BackgroundCompilation
+ *                   -XX:CompileCommand=dontinline,TestArrayAccessAboveRCAfterRCCastIIEliminated::notInlined
+ *                   -XX:+StressIGVN -XX:StressSeed=94546681 TestArrayAccessAboveRCAfterRCCastIIEliminated
+ * @run main/othervm TestArrayAccessAboveRCAfterRCCastIIEliminated


Suggested change

* @run main/othervm TestArrayAccessAboveRCAfterRCCastIIEliminated

* @run main TestArrayAccessAboveRCAfterRCCastIIEliminated

Detail, optional.

Actually, shouldn't I have kept -XX:-BackgroundCompilation for this one?

I think it would be great to have one run with absolutely no flags.

But then it's not even guaranteed that the compilation completes? I'm not sure I understand the rational.

@eme64 can you please explain why a run without flags make sense?

@rwestrel we internally have lots of different runs with different flags. Sometimes bugs only show under certain flag combinations. If you always have the flags on in the test already, then some combinations may not be effective. But if you think that some flags MUST always be on for the test to make any sense, then keep them, I guess.

TobiHartmann

Great job coming up with these tests, Roland!

Did you check if the other usages of _range_check_dependency via CastIINode::has_range_check are still needed? Seems to me as if at least the checks in PhaseIdealLoop::match_fill_loop can be removed.

TobiHartmann · 2024-04-22T11:10:52Z

src/hotspot/share/opto/compile.cpp

+    case Op_CastII: {
+      remove_range_check_cast(n->as_CastII());
+    }
+    break;


Indentation is off.

TobiHartmann · 2024-04-22T11:12:02Z

src/hotspot/share/opto/compile.cpp

+  if (cast->has_range_check()) {
+    // Range check CastII nodes feed into an address computation subgraph. Remove them to let that subgraph float freely.
+    // For memory access or integer divisions nodes that depend on the cast, record the dependency on the cast's control
+    // as a precedence edge, so they can't float above the cast in case that cast's narrowed type helped eliminated a


Suggested change

// as a precedence edge, so they can't float above the cast in case that cast's narrowed type helped eliminated a

// as a precedence edge, so they can't float above the cast in case that cast's narrowed type helped eliminate a

TobiHartmann · 2024-04-22T11:44:27Z

src/hotspot/share/opto/compile.cpp

+      Node* m = wq.at(next);
+      for (DUIterator_Fast imax, i = m->fast_outs(imax); i < imax; i++) {
+        Node* use = m->fast_out(i);
+        if (use->is_Mem() || use->Opcode() == Op_DivI || use->Opcode() == Op_DivL) {


Op_ModI and Op_ModL are missing here. And isn't this too strong in cases where we can prove that the operand is non-zero? Could you re-use PhaseIterGVN::no_dependent_zero_check? Please also add corresponding tests.

Looking at PhaseIterGVN::no_dependent_zero_check, I noticed that UDiv[I/L]Node and UMod[I/L]Node are not handled but I think they should. I think this was missed when these nodes where added by JDK-8282221. One can probably extend @chhagedorn's test from JDK-8259227 to trigger the same issue.

Op_ModI and Op_ModL are missing here.

Good catch! I added test cases for Op_ModI and Op_ModL , the unsigned variants and the also the DivMod variants. I also fixed the patch so it handles all of them.

And isn't this too strong in cases where we can prove that the operand is non-zero?

I don't think it's too strong. The operand can be non zero because of a range check CastII somewhere along the subgraph that starts at the node's second input. In that case, PhaseIterGVN::no_dependent_zero_check would return true but removing the range CastII would cause the bugs that are triggered by the test case.

Looking at PhaseIterGVN::no_dependent_zero_check, I noticed that UDiv[I/L]Node and UMod[I/L]Node are not handled but I think they should. I think this was missed when these nodes where added by JDK-8282221. One can probably extend @chhagedorn's test from JDK-8259227 to trigger the same issue.

That seems like a different problem that out of the scope of this particular issue.

I realized that I didn't understand your comment when I replied.
What you're saying, I think, is that if we have, say, a CastII that's input to a DivI node, if the input to that cast is non zero, then we don't need to add the CastII control as dependency to the DivI. The problem, I think, is that the CastII could be input to say an AddI node which would then be input to the DivI. What we would then need to know is whether if we remove the CastII, the AddI is still non null or not. That doesn't seem straightforward because this is done once we have no igvn instance to propagate types anymore. So, while I agree this is conservative, it still seems like the most reasonable fix.

What you're saying, I think, is that if we have, say, a CastII that's input to a DivI node, if the input to that cast is non zero, then we don't need to add the CastII control as dependency to the DivI

Yes, that was my point.

That doesn't seem straightforward because this is done once we have no igvn instance to propagate types anymore. So, while I agree this is conservative, it still seems like the most reasonable fix.

Right, we can still go down that path if it ever becomes necessary.

That seems like a different problem that out of the scope of this particular issue.

Could you please file a follow-up bug for that?

I filed https://bugs.openjdk.org/browse/JDK-8332268

TobiHartmann · 2024-04-22T12:42:12Z

test/hotspot/jtreg/compiler/rangechecks/TestArrayAccessAboveRCAfterRCCastIIEliminated.java

+ *                   -XX:+StressIGVN TestArrayAccessAboveRCAfterRCCastIIEliminated
+ * @run main/othervm -XX:-TieredCompilation -XX:-UseOnStackReplacement -XX:-BackgroundCompilation
+ *                   -XX:CompileCommand=dontinline,TestArrayAccessAboveRCAfterRCCastIIEliminated::notInlined
+ *                   -XX:+StressIGVN -XX:StressSeed=94546681 TestArrayAccessAboveRCAfterRCCastIIEliminated


Error: VM option 'StressIGVN' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions.

Fixed in new commit.

rwestrel · 2024-05-03T10:13:17Z

Thanks for reviewing this.

Did you check if the other usages of _range_check_dependency via CastIINode::has_range_check are still needed? Seems to me as if at least the checks in PhaseIdealLoop::match_fill_loop can be removed.

I did but was fairly conservative. In the case of PhaseIdealLoop::match_fill_loop, I don't think this change makes a difference: if we don't need the check for CastIINode::has_range_check there then it's true with or without that change.

TobiHartmann · 2024-05-14T20:41:11Z

I did but was fairly conservative. In the case of PhaseIdealLoop::match_fill_loop, I don't think this change makes a difference: if we don't need the check for CastIINode::has_range_check there then it's true with or without that change.

Right, maybe we can put that into the follow-up bug.

TobiHartmann

Looks good to me.

rwestrel · 2024-05-15T07:15:58Z

@eme64 do you need to review the updated change? Also can you answer the question you left unanswered about the test case:

"can you please explain why a run without flags make sense?"

eme64 · 2024-05-15T07:24:33Z

src/hotspot/share/opto/compile.cpp

+        if (use->is_Mem() || use->Opcode() == Op_DivI || use->Opcode() == Op_DivL ||
+            use->Opcode() == Op_ModI || use->Opcode() == Op_ModL || use->Opcode() == Op_UDivI ||
+            use->Opcode() == Op_UDivL || use->Opcode() == Op_UModI || use->Opcode() == Op_UModL) {


This kinda smells like it should be its own method. Seems we do not have a superclass for all Mod/Div nodes. Maybe we should have that? Or otherwise just a Node::is_div_or_mod() method?

eme64

I suggest you refactor the DIV/MOD checks, but otherwise I'm ok with the updates.

rwestrel · 2024-05-15T12:02:39Z

What about the new commit with the Node::is_div_or_mod() method @eme64 ?

eme64

@rwestrel thanks for the update, looks good!

rwestrel · 2024-05-15T12:41:59Z

I did but was fairly conservative. In the case of PhaseIdealLoop::match_fill_loop, I don't think this change makes a difference: if we don't need the check for CastIINode::has_range_check there then it's true with or without that change.

Right, maybe we can put that into the follow-up bug.

Should there be another follow up bug then? Or did I not understand what the follow up bug was about?

TobiHartmann · 2024-05-15T17:11:16Z

Should there be another follow up bug then? Or did I not understand what the follow up bug was about?

Right, feel free to file a new one but I think to just keep track of it, we can as well add it to JDK-8332268 for now.

rwestrel · 2024-05-16T07:23:36Z

Should there be another follow up bug then? Or did I not understand what the follow up bug was about?

Right, feel free to file a new one but I think to just keep track of it, we can as well add it to JDK-8332268 for now.

I filed: https://bugs.openjdk.org/browse/JDK-8332356

rwestrel · 2024-05-16T07:24:25Z

Thanks for the reviews @TobiHartmann and @eme64

rwestrel · 2024-05-16T07:24:30Z

/integrate

openjdk · 2024-05-16T07:25:14Z

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

fe8a2af: 8307778: com/sun/jdi/cds tests fail with jtreg's Virtual test thread factory
95f79c6: 8332253: Linux arm32 build fails after 8292591
b687aa5: 8332176: Refactor ClassListParser::parse()
4083255: 8316138: Add GlobalSign 2 TLS root certificates
43b109b: 8330066: HeapDumpPath and HeapDumpGzipLevel VM options do not mention HeapDumpBeforeFullGC and HeapDumpAfterFullGC
7cff04f: 8330276: Console methods with explicit Locale
8a4315f: 8331987: Enhance stacktrace clarity for CompletableFuture CancellationException
491b3b4: 8332256: Shenandoah: Do not visit heap threads during shutdown
9c02c8d: 8332255: Shenandoah: Remove duplicate definition of init mark closure
42ccb74: 8331940: ClassFile API ArrayIndexOutOfBoundsException with certain class files
... and 19 more: https://git.openjdk.org/jdk/compare/7ce4a13c0a891e606480e138f4025ffa328a18b3...master

Your commit was automatically rebased without conflicts.

openjdk · 2024-05-16T07:25:19Z

@rwestrel Pushed as commit ab8d7b0.

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

dholmes-ora · 2024-05-16T09:06:55Z

This is causing a crash in compiler/rangechecks/TestArrayAccessAboveRCAfterRCCastIIEliminated.java

Aarch64 only so far:

A fatal error has been detected by the Java Runtime Environment:

Internal Error (/opt/mach5/mesos/work_dir/slaves/a4a7850a-7c35-410a-b879-d77fbb2f6087-S6223/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/c30fdcec-3ee7-44a9-bfc5-38869fd48e4b/runs/4e34865c-00ca-43a6-87eb-21db2db1c8ab/workspace/open/src/hotspot/share/opto/gcm.cpp:1423), pid=1811107, tid=1811123

assert(false) failed: graph should be schedulable

will get a bug filed

chhagedorn · 2024-05-16T09:11:17Z

will get a bug filed

@rwestrel Filed JDK-8332369, can you have a look at it?

eme64 · 2024-05-16T09:11:55Z

Hmm seems we only ran test from our side for v01, and the test there had a crash too, though different.
-ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation
These seem to be the flags.

TobiHartmann · 2024-05-16T14:44:29Z

Right, I did run testing on an early draft and v01 and only saw the Error: VM option 'StressIGVN' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions issue I reported above. We missed re-running testing of later versions.

test and fix

182cd4f

openjdk bot added the rfr Pull request is ready for review label Mar 19, 2024

openjdk bot added the hotspot-compiler hotspot-compiler-dev@openjdk.org label Mar 19, 2024

eme64 suggested changes Mar 28, 2024

View reviewed changes

rwestrel added 2 commits March 28, 2024 14:08

Merge branch 'master' into JDK-8324517

9e3851b

review

0de61cb

eme64 approved these changes Apr 5, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Apr 5, 2024

Merge branch 'master' into JDK-8324517

25e9d18

TobiHartmann suggested changes Apr 22, 2024

View reviewed changes

TobiHartmann reviewed Apr 22, 2024

View reviewed changes

rwestrel added 3 commits May 2, 2024 17:17

Merge branch 'master' into JDK-8324517

4d93fd6

review

ceb30c1

test fix

5cc658b

TobiHartmann approved these changes May 14, 2024

View reviewed changes

eme64 reviewed May 15, 2024

View reviewed changes

eme64 approved these changes May 15, 2024

View reviewed changes

rwestrel added 2 commits May 15, 2024 09:27

Merge branch 'master' into JDK-8324517

706fc55

Node::is_div_or_mod()

67d2a05

eme64 approved these changes May 15, 2024

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label May 16, 2024

openjdk bot closed this May 16, 2024

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

	assert(cast->in(0) != nullptr, "");
	assert(cast->in(0) != nullptr, "All RangeCheck CastII must have a control dependency");

	* @run main/othervm TestArrayAccessAboveRCAfterRCCastIIEliminated
	* @run main TestArrayAccessAboveRCAfterRCCastIIEliminated

	// as a precedence edge, so they can't float above the cast in case that cast's narrowed type helped eliminated a
	// as a precedence edge, so they can't float above the cast in case that cast's narrowed type helped eliminate a

8324517: C2: crash in compiled code because of dependency on removed range check CastIIs #18377

8324517: C2: crash in compiled code because of dependency on removed range check CastIIs #18377

Conversation

rwestrel commented Mar 19, 2024 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

Webrev

bridgekeeper bot commented Mar 19, 2024

openjdk bot commented Mar 19, 2024 • edited Loading

openjdk bot commented Mar 19, 2024

mlbridge bot commented Mar 19, 2024 • edited Loading

Webrevs

eme64 left a 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

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

Choose a reason for hiding this comment

rwestrel commented Mar 28, 2024

rwestrel commented Apr 5, 2024

eme64 commented Apr 5, 2024

eme64 left a 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TobiHartmann left a 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

rwestrel May 3, 2024 • edited Loading

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

rwestrel commented May 3, 2024

TobiHartmann commented May 14, 2024

TobiHartmann left a comment

Choose a reason for hiding this comment

rwestrel commented May 15, 2024

Choose a reason for hiding this comment

eme64 left a comment

Choose a reason for hiding this comment

rwestrel commented May 15, 2024 • edited Loading

eme64 left a comment

Choose a reason for hiding this comment

rwestrel commented May 15, 2024

TobiHartmann commented May 15, 2024

rwestrel commented May 16, 2024

rwestrel commented May 16, 2024

rwestrel commented May 16, 2024

openjdk bot commented May 16, 2024

openjdk bot commented May 16, 2024

dholmes-ora commented May 16, 2024

A fatal error has been detected by the Java Runtime Environment:

assert(false) failed: graph should be schedulable

chhagedorn commented May 16, 2024 • edited Loading

eme64 commented May 16, 2024

TobiHartmann commented May 16, 2024

rwestrel commented Mar 19, 2024 •

edited by openjdk bot

Loading

openjdk bot commented Mar 19, 2024 •

edited

Loading

mlbridge bot commented Mar 19, 2024 •

edited

Loading

rwestrel May 3, 2024 •

edited

Loading

rwestrel commented May 15, 2024 •

edited

Loading

chhagedorn commented May 16, 2024 •

edited

Loading