RFR: 8267952: async logging supports to dynamically change tags and decorators [v2]

[David Holmes]

On Thu, 10 Jun 2021 19:11:28 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> It is the load/store of `uint _decorators;` that needs to be atomic.
>
> I can't overload copy constructor and assignment operator using Atomic because there are many places we don't need atomic operation at all. Of course, I can provide two member functions atomic_load/store for `LogDecorators`.  TBH, I feel I am uglifying code.  Actually I did it, the generated code is exactly same. that's why I am reluctant to use them.
> 
> Yes, the atomicity isn't provided by C++. It is provided by both c++ and underneath processors. As long as load/store are aligned and the ALU is 32-bit or wider,  store like c42 is atomic.
> 
> 
> 0000000000000c40 <LogOutput::set_decorators(LogDecorators const&)>:
>      c40:       8b 06                   mov    (%rsi),%eax
>      c42:       89 47 20                mov    %eax,0x20(%rdi)
>      c45:       c3                      retq
> 
> 
> A RCU algorithm never be straightforward. That's why I try to write comments here.  It's not me who introduce this code. I just try to explain how it works. 
> 
> How about this? Could you submit this patch to the internal test infra and see if it can pass tier1~tier7? if it can't, we refactor this code.

First my apologies for getting muddled by this code. We don't use class types in lock-free algorithms so don't have a means to express atomic updates to objects this way. We still need the accesses to be atomic, but have no way to express that in the source code when the code has been written this way.

The issue is not whether the generated code is exactly the same as it often will be, especially on x86. The issue is how we show in our source code that we have lock-free racy accesses to variables and that we are aware of this and have applied all the necessary atomic operations and/or orderAccess operations to ensure the races result in correct operation of the code. Unfortunately that is not currently feasible  due to the way this code has been written. I think fixing that aspect will need to be a future RFE.

I had already submitted tiers 1-3 with no problem, but have now submitted tiers 4-7.

I still need to re-examine the RCU code to understand the broader context here.

Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/4408