RFR: 8361752: Double free in CompileQueue::delete_all after JDK-8357473

[Aleksey Shipilev]

On Mon, 14 Jul 2025 17:28:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/compiler/compileBroker.cpp line 394:
>> 
>>> 392:     ml.notify_all();
>>> 393:   }
>>> 394: 
>> 
>> What about other compiler threads which still in process of compiling for blocking tasks? They still need it CompileTask object.
>> `delete_all()` is called by one compiler thread which finished compilation but other threads may not.
>> 
>> I don't see any compiler thread checks `shut_down` state to stop compilation.
>
> AFAIU, that's the point of the existing protocol to force _waiters_ to delete the task: the blocking waiter would wait for compiler thread to complete the task one way or the other. This PR makes that protocol even stronger: _only_ blocking waiters are allowed to delete the blocking task.

Ah, your question is what happens if we notify here, and compilations are still running? Well, I think current protocol should nominally allow waiters to wait until compilation is over and then allow them to delete the task. But then I see `wait_for_compilation` can exit when compilation is shut down:


    while (!task->is_complete() && !is_compilation_disabled_forever()) {
      ml.wait();
    }


This will proceed to delete the task while compiler thread is running. Grrr. Looks to be another hole in this protocol.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26294#discussion_r2205459401