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

[Xin Liu]

On Fri, 18 Jun 2021 01:21:59 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Support dynamic reconfiguration for async logging. 2 unittests are provided.
>> The regression test discovers a race condition in LogTagSet::log() even with
>> synchronous logging. It's not MT-safe if context switch happens between the
>> creation of LogDecorations  and LogOutputList::Iterator. fixed.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix VC++ warning C4099

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_
> 
> On 18/06/2021 12:00 pm, David Holmes wrote:
> 
> > Hi Xin,
> > On 18/06/2021 9:29 am, Xin Liu wrote:
> > > > Support dynamic reconfiguration for async logging. 2 unittests are
> > > > provided.
> > > > The regression test discovers a race condition in LogTagSet::log()
> > > > even with
> > > > synchronous logging. It's not MT-safe if context switch happens
> > > > between the
> > > > creation of LogDecorations? and LogOutputList::Iterator. fixed.
> > > 
> > > 
> > > Xin Liu has updated the pull request incrementally with one additional
> > > commit since the last revision:
> > > ?? Use Atomic::load/store for decorators.
> > > ?? This patch also installed a sanity check which will assert that
> > > ?? LogOutput::_decorators is subset of LogDecocrations. It will disclose
> > > ?? more information if the assertion fails.
> > 
> > 
> > I'm putting these latest changes through tier6 and 7 testing - but there
> > is a big backlog at the moment so I don't know when I will get results.
> 
> Not complete yet but the asynclogTest failed again:
> 
> - one crash with the SEGV in flockfile
> - one crash with assert(bitmask == _decorators._decorators) failed:
> LogOutput: 4095 decorations: 0 message = ConcurrentLogsite 0 emits a log
> 
> David
> -----
> 
> > Looking at the code I still find it very difficult to see what actions
> > can happen concurrently and what mechanism ensure correct concurrent
> > actions. The wait_until_no_readers() logic doesn't make sense to me as I
> > can't see what stops the number of readers from increasing the moment
> > after it was read as zero! The relationships between all the different
> > objects is far from clear to me.
> > David
> > -----

Thank you. I see. we haven't solved any of two crash sights.  
Current synchronization mechanism doesn't work for both tags or decorators.  
Let me think of it.

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

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