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

David Holmes dholmes at openjdk.java.net
Thu Jun 10 13:02:20 UTC 2021


On Thu, 10 Jun 2021 07:06:05 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> To support machines without unaligned memory access, C++ defines "alignment requirement" for class and struct. 
>> Not only sizeof(LogDecorators) == sizeof(uint) == 4, C++ can also guarantee that alignof(logDecorators) is 4. 
>> Therefore, it's impossible that to unaligned access for its field _decorators. 
>> 
>> 
>> class LogDecorators {
>>   uint _decorators;
>> };
>> 
>> 
>> Therefore, I think the current code which use normal assignment is atomic. Of course, using Atomic::store manifests it's an atomic store. I will try to use Atomic::store().
>
> Could you take a look at my argument? IMHO, C++ can guarantee the following code is atomic. 
> Alignment shouldn't an issue. 
> 
> 
> void LogOutput::set_decorators(const LogDecorators& decorators) {
>     _decorators = decorators;
> }
> 
> 
> I manage to support the following code. The generated code is exactly same, but it needs some tricks of c++ meta-programming.  Is it worthy?  if you still insist we should use Atomic::store, how about I create a separate JBS issue and submit a patch?  My concern is that Atomic::load/store makes current code messy. 
> 
> 
> void LogOutput::set_decorators(const LogDecorators& decorators) {
>   Atomic::store(&_decorators, decorators);
> }

C++ makes no guarantees about atomicity unless using C++ atomic operations. Yes they probably are atomic but we don't rely on "probably". If a variable is being accessed lock-free and can take part in data-race then please just use Atomic::load and store for simple accesses (assuming they are correct in the context of how the variable can be used concurrently).

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

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


More information about the hotspot-runtime-dev mailing list