RFR: 8305670: Performance regression in LockSupport.unpark with lots of idle threads [v7]

[David Holmes]

On Fri, 5 May 2023 20:59:58 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> The second `thread_acquire` most certainly does need to synchronize with the
> code in `ensure_join()` that does a `release_set_thread` of a nullptr. If that code
> set a nullptr before we could read a non-nullptr value a second time, then we can
> make no inferences about what `_tlh` contains. So I see the second thread_acquire
> as matching up with the release_set_thread in ensure_join.

The only memory value of interest is the read of eetop. The release/acquire have no affect on the reading or writing of that field itself. We would only need acquire semantics when reading the potentially null eetop if we were then to read another memory value that would be written prior to eetop being set to null. That is not the case hence the acquire semantics are unnecessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13519#discussion_r1186977791