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

[Aleksey Shipilev]

On Thu, 30 Jan 2025 18:49:40 GMT, Aleksey Shipilev <shade at 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