RFR: 8305819: LogConfigurationTest intermittently fails on AArch64

[Johan Sjölen]

On Wed, 3 May 2023 09:32:52 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> @theRealAph I didn't mean that current code is like linux kernel RCU, which is well-documented synchronization. I mean current solution in UnifiedLog borrow the idea.
>> 
>> Yes, it does borrow, the idea, but AFAICS without understanding just how tricky it is. And gets it all wrong as a consequence.
>> 
>>> Analysis so far leads us to believe this error manifests in weak memory model, right? it's the processor reorders some instructions but not compiler optimizations. Do we really need to consider that MACRO?
>> 
>> I don't think that's the real problem. While HotSpot will very probably never be standard C++, we usually try to write standard-correct code, going outside the standard guarantees when we really need to.  I don't think this is such a case.
>> 
>> Data races are undefined behaviour. With undefined behaviour, all bets are off. You cannot test for the absence of bugs, only their presence.
>
>> if we replace the current solution with read/write lock, I guess we won't lose much in terms of performance. but this seems a separated task.
> 
> Let's do that. Then we'll have code that's known to be correct, and we can all do other things. 😁

> > if we replace the current solution with read/write lock, I guess we won't lose much in terms of performance. but this seems a separated task.
> 
> Let's do that. Then we'll have code that's known to be correct, and we can all do other things. grin

https://github.com/openjdk/jdk/pull/9838

Here's my old PR for a read-write lock that was meant to replace this RCU mechanism :-). It's a simple counter based one, which I borrowed from ZGC. If anyone wants to pick up this code then feel free to do so (with me as contributor and Oracle copyright notice).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13421#discussion_r1183460955