RFR: 8348960: [leyden] compiler/c1/TestConcurrentPatching.java is stuck [v2]

[Aleksey Shipilev]

On Thu, 30 Jan 2025 19:57:59 GMT, Vladimir Ivanov <vlivanov at 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