RFR: 8358343: [leyden] Drop notify_all in CompilationPolicyUtils::Queue::pop

[Igor Veresov]

On Tue, 3 Jun 2025 17:59:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Found this when reading premain-vs-mainline webrev. Mainline does not have `notify_all` in this method:
> https://github.com/openjdk/jdk/blob/c382da579884c28f2765b2c6ba68c0ad4fdcb2ce/src/hotspot/share/compiler/compilationPolicy.hpp#L85-L92
> 
> But if you remove `notify_all()` in `premain`, then tests start to deadlock, see bug for a sample. The culprit is `CompilationPolicy::flush_replay_training_at_init`, which is only present in premain. I fixed it by using timed waits, which obviates the need for extra notifications. We only enter this method with `-XX:+AOTVerifyTrainingData`, so we don't care much about its performance. This is IMO better than doing a questionable `notify_all` followed by `wait` in load-bearing code.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` (5x, no timeouts yet; still running more iterations)

Is there a reason why can't we just do the processing work in the thread calling the flush instead of waiting for the replay thread? That is, why not make it be like this:


void CompilationPolicy::flush_replay_training_at_init(TRAPS) {
  InstaceKlass* ik;
  do {
    ik = _training_replay_queue.try_pop(TrainingReplayQueue_lock, THREAD);
    if (ik != nullptr) {
      replay_training_at_init_impl(ik, THREAD);
    }
  } while (ik != nullptr);
}

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

PR Comment: https://git.openjdk.org/leyden/pull/74#issuecomment-2947960746