RFR: 8355627: Don't use ThreadCritical for EventLog list [v2]

[Aleksey Shipilev]

On Mon, 5 May 2025 13:46:35 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> I saw no point in enforcing memory ordering mode here, as it looks like we only did `ThreadCritical` for mutual exclusion. Note that we do not have a matching acquire on list traversals, so seqcst/release on list additions would be incomplete. That only reinforces my original thinking: we are riding on memory ordering given by something else, I'd guess the initialization sequence itself.
>> 
>> But I won't quibble, it is a very minor optimization.
>
> I don't believe we need reader side barrier, given the `conservative` order on writer side. @shipilev any opinion?

Well, if we are going fully pedantic here, we only need to make sure that the `EventLog::_next` is properly visible to the code that traverses the `EventLog` list. This realistically only matters if there are no synchronization points in between those, which I suspect are plenty. E.g. this is the same thing that make all other init code robust in practice: things that happen at init are good to go.

If you want to cover the path to be fully 100% bullet-proof and squeeze some performance at the same time, then I think `cmpxchg` to `Events::_logs` should be `release` and loads from there should be `acquire`-s.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24954#discussion_r2073707374