RFR: 8348960: [leyden] compiler/c1/TestConcurrentPatching.java is stuck
This is seen in GHA, and reproduces well on my machine as well: $ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout> Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo. The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations. Additional testing: - [ ] GHA - [ ] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x ------------- Commit messages: - No iffs, no butts - Fix Changes: https://git.openjdk.org/leyden/pull/30/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=30&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348960 Stats: 20 lines in 1 file changed: 18 ins; 0 del; 2 mod Patch: https://git.openjdk.org/leyden/pull/30.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/30/head:pull/30 PR: https://git.openjdk.org/leyden/pull/30
On Wed, 29 Jan 2025 18:19:15 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [ ] GHA - [ ] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
Feel free to integrate on my behalf. ------------- PR Comment: https://git.openjdk.org/leyden/pull/30#issuecomment-2622695789
On Wed, 29 Jan 2025 18:19:15 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [ ] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
First GHA run is clean, use to reliably fail. Running GHA again to confirm. ------------- PR Comment: https://git.openjdk.org/leyden/pull/30#issuecomment-2622819287
On Wed, 29 Jan 2025 18:19:15 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [x] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
100x runs of `compiler/c1/TestConcurrentPatching.java` are also done without timeouts. I think this confirms the fix works. ------------- PR Comment: https://git.openjdk.org/leyden/pull/30#issuecomment-2622837448
On Wed, 29 Jan 2025 18:19:15 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [x] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
Ran 700x `compiler/c1/TestConcurrentPatching.java` overnight, and no timeouts. I think we are good to go. ------------- PR Comment: https://git.openjdk.org/leyden/pull/30#issuecomment-2623892690
On Wed, 29 Jan 2025 18:19:15 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [x] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
Looks correct. However, it would be nice not to rely on recursion even though I agree it will eventually stop. I think you can do fairly simply that by refactoring `transfer_pending`. If you relocate the while loop (pop and triage) into a separate method (`do_transfer_pending`) that you call here then you can also call that method from `purge_stale_tasks` inside a loop instead of recursing into `transfer_pending`. The new method would need to return true if a further purge is needed (i.e. `added_stale_tasks && !added_new_tasks`) so you can decide whether to call `purge_tasks` here and whether to continue looping inside `purge_tasks`. ------------- Marked as reviewed by adinn (Committer). PR Review: https://git.openjdk.org/leyden/pull/30#pullrequestreview-2584368450
On Thu, 30 Jan 2025 16:13:09 GMT, Andrew Dinn <adinn@openjdk.org> wrote:
However, it would be nice not to rely on recursion even though I agree it will eventually stop.
IMO an optional argument in `CompileQueue::purge_stale_tasks()` to control whether `transfer_pending()` is called or not would enable an easy way to turn the recursion into a (nested) loop. ------------- PR Comment: https://git.openjdk.org/leyden/pull/30#issuecomment-2625250755
On Wed, 29 Jan 2025 18:19:15 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [x] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
Looks good. Good catch! ------------- Marked as reviewed by vlivanov (Committer). PR Review: https://git.openjdk.org/leyden/pull/30#pullrequestreview-2584687591
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [x] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Avoid recursion in more bullet-proof way ------------- Changes: - all: https://git.openjdk.org/leyden/pull/30/files - new: https://git.openjdk.org/leyden/pull/30/files/1159730d..1e1ec544 Webrevs: - full: https://webrevs.openjdk.org/?repo=leyden&pr=30&range=01 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=30&range=00-01 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.org/leyden/pull/30.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/30/head:pull/30 PR: https://git.openjdk.org/leyden/pull/30
On Thu, 30 Jan 2025 18:49:40 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [x] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
Avoid recursion in more bullet-proof way
Thinking more about it, does the bug arise in `CompileQueue::free_all()` due to absence of `purge_stale_task()` call? The only other place where `transfer_pending()` is used is `CompileQueue::get()`, but I don't see how it can avoid calling `purge_stale_task()`. Would a `purge_stale_task()` call in `CompileQueue::free_all()` fix the problem as well? Or are compiler threads simply stuck in `while (_first == nullptr) { ... }` in `CompileQueue::get()` waiting for more compilations while stale task queue remains non-empty? Overall, I'd prefer an explicit call to `purge_stale_task()` rather than making all `transfer_pending()` calls becoming a point where MCQ lock can be released. ------------- PR Comment: https://git.openjdk.org/leyden/pull/30#issuecomment-2625427093 PR Comment: https://git.openjdk.org/leyden/pull/30#issuecomment-2625448784
On Thu, 30 Jan 2025 19:57:59 GMT, Vladimir Ivanov <vlivanov@openjdk.org> wrote:
Or are compiler threads simply stuck in `while (_first == nullptr) { ... }` in `CompileQueue::get()` waiting for more compilations while stale task queue remains non-empty?
I think this is the case: compilers are idle and never get to purge the tasks. So the "normal" lifecycle for stale task handling does not work. I understand the concern about releasing the MCQ lock in `transfer_pending`. Thinking about this, we can fix the deadlock in two ways: a) perform the purge right when the problem is constructed (this is current version); b) make sure we purge the tasks before we block the compiler thread. For (b), a potential place that resolves some of this is before `locker.wait(5*1000);` that parks the compiler thread. We can do `purge_stale_task` before it? It will still release MCQ, but it looks fine given we are about to release it for `wait` anyway? Made this patch locally, and it seems to pass the test without deadlock: diff --git a/src/hotspot/share/compiler/compileBroker.cpp b/src/hotspot/share/compiler/compileBroker.cpp index 0770c1112d5..1f6ae4a8f5d 100644 --- a/src/hotspot/share/compiler/compileBroker.cpp +++ b/src/hotspot/share/compiler/compileBroker.cpp @@ -495,6 +495,8 @@ CompileTask* CompileQueue::get(CompilerThread* thread) { break; } + purge_stale_tasks(); + // If there are no compilation tasks and we can compile new jobs // (i.e., there is enough free space in the code cache) there is // no need to invoke the GC. ------------- PR Comment: https://git.openjdk.org/leyden/pull/30#issuecomment-2627662040
On Thu, 30 Jan 2025 18:49:40 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [x] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
Avoid recursion in more bullet-proof way
I like the version with extra `purge_stale_tasks()` in `CompileQueue::get`. Releasing MCQ lock there looks benign. ------------- PR Comment: https://git.openjdk.org/leyden/pull/30#issuecomment-2628245808
On Fri, 31 Jan 2025 19:46:45 GMT, Vladimir Ivanov <vlivanov@openjdk.org> wrote:
Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
Avoid recursion in more bullet-proof way
I like the version with extra `purge_stale_tasks()` in `CompileQueue::get`. Releasing MCQ lock there looks benign.
500x runs of `TestConcurrentPatching.java` passes. `all` test suite passes without regressions (there are some Leyden-specific problems that reproduce even without this patch). I would like to integrate this version, if you agree @iwanowww? ------------- PR Comment: https://git.openjdk.org/leyden/pull/30#issuecomment-2628911461
On Thu, 30 Jan 2025 18:49:40 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [x] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
Avoid recursion in more bullet-proof way
Good. Except we also need to take care of repeated `transfer_pending` from inside of `purge_stale_tasks`, which may generate more stale tasks. And we cannot just leave pending tasks behind when we are about to block. So this IMO necessitates a bit more scaffolding. See new version. I'll run it overnight. I also left the `is_empty` -> `pop` rewrite, because `is_empty` is racy and not supposed to be used during modifications, see the non-blocking queue docs. ------------- PR Comment: https://git.openjdk.org/leyden/pull/30#issuecomment-2628442672
On Wed, 29 Jan 2025 18:19:15 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [x] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
Actually, I don't think we need a loop in any form, either recursive or nested. We only need to prevent the recursive re-entry. I agree this is trivially doable with the optional boolean argument in `purge_stale_tasks`. See new version. I am running the stress testing again. ------------- PR Comment: https://git.openjdk.org/leyden/pull/30#issuecomment-2625301347
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [x] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Move the fix to CompileTask.get ------------- Changes: - all: https://git.openjdk.org/leyden/pull/30/files - new: https://git.openjdk.org/leyden/pull/30/files/1e1ec544..f8a10da9 Webrevs: - full: https://webrevs.openjdk.org/?repo=leyden&pr=30&range=02 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=30&range=01-02 Stats: 38 lines in 2 files changed: 16 ins; 19 del; 3 mod Patch: https://git.openjdk.org/leyden/pull/30.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/30/head:pull/30 PR: https://git.openjdk.org/leyden/pull/30
On Fri, 31 Jan 2025 21:40:44 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [x] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
Move the fix to CompileTask.get
Looks good. src/hotspot/share/compiler/compileBroker.cpp line 421:
419: assert(_lock->owned_by_self(), "must own lock"); 420: 421: CompileTask* task;
I assume these changes aren't strictly needed (`_queue` is always drained under the lock). ------------- Marked as reviewed by vlivanov (Committer). PR Review: https://git.openjdk.org/leyden/pull/30#pullrequestreview-2590609080 PR Review Comment: https://git.openjdk.org/leyden/pull/30#discussion_r1939787326
On Mon, 3 Feb 2025 17:43:26 GMT, Vladimir Ivanov <vlivanov@openjdk.org> wrote:
Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
Move the fix to CompileTask.get
src/hotspot/share/compiler/compileBroker.cpp line 421:
419: assert(_lock->owned_by_self(), "must own lock"); 420: 421: CompileTask* task;
I assume these changes aren't strictly needed (`_queue` is always drained under the lock).
While `_queue` is drained under the lock, it is being _added to_ without a lock, which means we are using `empty` under concurrent queue modification, which is, per NBQ docs, not guaranteed to work well. (ABA problems.) ------------- PR Review Comment: https://git.openjdk.org/leyden/pull/30#discussion_r1941198326
On Tue, 4 Feb 2025 13:43:27 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
src/hotspot/share/compiler/compileBroker.cpp line 421:
419: assert(_lock->owned_by_self(), "must own lock"); 420: 421: CompileTask* task;
I assume these changes aren't strictly needed (`_queue` is always drained under the lock).
While `_queue` is drained under the lock, it is being _added to_ without a lock, which means we are using `empty` under concurrent queue modification, which is, per NBQ docs, not guaranteed to work well. (ABA problems.)
Thanks for the clarification. I missed that `NonblockingQueue::empty()` is not thread-safe. ------------- PR Review Comment: https://git.openjdk.org/leyden/pull/30#discussion_r1941699216
On Fri, 31 Jan 2025 21:40:44 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [x] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
Move the fix to CompileTask.get
Thanks! ------------- PR Comment: https://git.openjdk.org/leyden/pull/30#issuecomment-2634009071
On Fri, 31 Jan 2025 21:40:44 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [x] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
Move the fix to CompileTask.get
@shipilev Your change (at version f8a10da9ae80c4edf98cd9510388fefc1794806e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/leyden/pull/30#issuecomment-2634013080
On Wed, 29 Jan 2025 18:19:15 GMT, Aleksey Shipilev <shade@openjdk.org> wrote:
This is seen in GHA, and reproduces well on my machine as well:
$ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout>
Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo.
The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations.
Additional testing: - [x] GHA - [x] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x
This pull request has now been integrated. Changeset: 59ef37a4 Author: Aleksey Shipilev <shade@openjdk.org> Committer: Vladimir Kozlov <kvn@openjdk.org> URL: https://git.openjdk.org/leyden/commit/59ef37a46afa55a96196780e6b3606bd67a1cb... Stats: 19 lines in 1 file changed: 17 ins; 0 del; 2 mod 8348960: [leyden] compiler/c1/TestConcurrentPatching.java is stuck Reviewed-by: adinn, vlivanov ------------- PR: https://git.openjdk.org/leyden/pull/30
participants (4)
-
Aleksey Shipilev
-
Andrew Dinn
-
duke
-
Vladimir Ivanov