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

[Aleksey Shipilev]

On Mon, 14 Jul 2025 17:40:56 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> 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.
>
> Can compiler thread delete its **own** blocking task when it finished. And let Java thread resume execution when compilation disabled as it do now but do nothing about task in such case?

I don't think that works. There is no "own" blocking task, there are nearly always two threads involved: the compiler thread and the waiter (Java) thread. Waiter is checking the task status under the lock. Logically, the last _user_ should delete the task, that is waiter. 

But I think we can handle this hole by ignoring the blocking task deletion during compiler shutdown. For the same reason described in PR body: we already leave cruft behind in that case, and it costs us quite a bit of complexity to deal with every corner case during shutdown. So it seems simpler to just drop the tasks on the floor in that corner case.

I did a variant of this in new commit, seems to still work well under stress testing. More testing is running now...

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

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