RFR: 8364501: Compiler shutdown crashes on access to deleted CompileTask

[Aleksey Shipilev]

On Fri, 8 Aug 2025 15:15:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> See the bug for more investigation. 
>> 
>> In short, with recent changes to `delete` `CompileTask`-s, we end up in the rare situation where we can access tasks that have been already deleted. The major and obivous mistake I committed myself with [JDK-8361752](https://bugs.openjdk.org/browse/JDK-8361752) in `CompileQueue::delete_all`: the code first `delete`-s, then asks for `next` (facepalms). 
>> 
>> Another case is less trivial, and mostly fix in abundance of caution: in `wait_for_completion`, we can exit while blocking task is still in queue. Current code skip deletions only when compiler is shutdown for compilation, but I think the condition should be stronger: unless the task is completed, we should assume it might carry the queue-ing `next`/`prev` pointers that `delete_all` would need, and skip deletion. Realistically, it would "leak" only on compiler shutdown, like before.
>> 
>> I have also put in some diagnostic code to catch the lifecycle issues like this more reliably, and cleaned up `next`, `prev` lifecycle to clearly disconnect the `CompileTasks` that are no longer in queue.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, reproducer no longer fails
>>  - [x] Linux AArch64 server fastdebug, `compiler`
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> src/hotspot/share/compiler/compileBroker.cpp line 509:
> 
>> 507:   }
>> 508:   task->set_next(nullptr);
>> 509:   task->set_prev(nullptr);
> 
> Should we do `task->prev()->set_next(task->next())` after some checks?

We do it at L494? Maybe I don't understand the question.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26696#discussion_r2263286402