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

[Andrew Dinn]

On Wed, 29 Jan 2025 18:19:15 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

Looks correct. However, it would be nice not to rely on recursion even though I agree it will eventually stop.

I think you can do fairly simply that by refactoring `transfer_pending`. If you relocate the while loop (pop and triage) into a separate method (`do_transfer_pending`) that you call here then you can also call that method from `purge_stale_tasks` inside a loop instead of recursing into `transfer_pending`. The new method would need to return true if a further purge is needed (i.e. `added_stale_tasks && !added_new_tasks`) so you can decide whether to call `purge_tasks` here and whether to continue looping inside `purge_tasks`.

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

Marked as reviewed by adinn (Committer).

PR Review: https://git.openjdk.org/leyden/pull/30#pullrequestreview-2584368450