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

[Xin Liu]

On Thu, 10 Jun 2021 12:49:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I see. I would like to convince reviewers first. I will add some comments here. 
>> 
>> I don't think loadload barrier is necessary.  volatile in c/c++ is a little bit different from Java. we can't fully apply JSR-133 here. Yes, we do need to make sure Atomic::add() happens before load of decorators. This is done by the implied memory barrier of `Atomic::add`.
>
> I have no idea why you mention volatile and jsr-133 here.
> 
> If there is an Atomic::add inside there then okay the necessary barrier may be in place. But it is not at all apparent there is an Atomic operation inside there, so given the order is important the comment needs to explain why an explicit barrier is not needed.

The following code uses `Atomic::add`. Actually, there's a hidden 3rd argument. it's a default parameter and I highlight it.  It is the conservative memory order emits a full memory barrier. I double-check the implementations on  x86/aarch64 and powerpc.


jint LogOutputList::increase_readers() {
  jint result = Atomic::add(&_active_readers, 1, /*memory_order_conservative*/);
  assert(_active_readers > 0, "Ensure we have consistent state");
  return result;
}

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

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