If it's a CopyOnWriteArray*List* we can iterate by index, instead of the for-each loop style. However, it may be good to focus on steady state application logging. For things only used during initialization there may not be much benefit. The test to detect memory allocation would be really useful, but I haven't had time to look at this. (If anyone wants to work on that that'd be great.)
One thing: currently StatusLogger creates special ParameterizedMessages without a reference to the original parameters to prevent memory leaks. Now that the formatting logic is separated out to ParameterFormatter, that can be optimized to an ObjectMessage (holding a StringBuilder?). The specialized ParameterizedMessage subclass can then be removed which is a nice simplification. Sent from my iPhone > On 2016/02/26, at 5:46, Matt Sicker <boa...@gmail.com> wrote: > > * StatusLogger (StatusListener list) > * LoggerContext (PropertyChangeListener list) > * AbstractConfiguration (ConfigurationListener list) > * PluginManager (String list of packages to scan) > * DefaultShutdownCallbackRegistry (Cancellable list) > * And some irrelevant usages in log4j-perf (they're intentionally using > CopyOnWriteArrayList/Set) > >> On 25 February 2016 at 14:18, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> Do you have a list? >> >> Ralph >> >>> On Feb 25, 2016, at 1:07 PM, Matt Sicker <boa...@gmail.com> wrote: >>> >>> So far I've found a couple places we use a CopyOnWriteArrayList for >>> listeners in StatusLogger and core.LoggerContext. I could refactor these >>> usages to use a custom set-like class like we use for the AppenderControl >>> set, but I don't know if it's worth it. >>> >>> -- >>> Matt Sicker <boa...@gmail.com> > > > > -- > Matt Sicker <boa...@gmail.com>
