harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Wu <wuyue...@gmail.com>
Subject Re: [classlib][modularity] Logging performance improvements (HARMONY-6362)
Date Tue, 27 Oct 2009 15:01:13 GMT
Good question. We may face more and more similar cases in future as
multi-core is the trend. an ideal solution is to detect if there is
concurrent module in classpath then we load it and use the improved
implementation otherwise we go back to the original.

On Tue, Oct 27, 2009 at 10:20 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> On 26/Oct/2009 20:33, Jesse Wilson (JIRA) wrote:
>> Logging performance improvements
>> --------------------------------
>>                  Key: HARMONY-6362
>>                  URL: https://issues.apache.org/jira/browse/HARMONY-6362
>>              Project: Harmony
>>           Issue Type: Improvement
>>           Components: Classlib
>>          Environment: SVN Revision: 829932
>>             Reporter: Jesse Wilson
>>             Priority: Minor
>> The logging module performs more synchronization and object
>> allocation than necessary. In particular, getHandlers() always needs
>> synchronization and creates an array. By adopting util.concurrent
>> features (CopyOnWriteArrayList) and coding to the common case (when
>> there are zero handlers) I saw a 2.5x improvement in throughput for
>> calls to logger.log(Level, String). In a benchmark that measures calls
>> to "logger.info", call time improved from 385000ns to 154000ns per message.
> The improvement in performance is impressive.  What is the contribution
> made by the use of the CopyOnWriteArrayList?  I'll tell you why I am
> asking...
> This would be our first dependency on util.concurrent from the logging
> module, and if the benefit is small then I'd prefer to see reduced
> coupling between the modules rather than a small improvement in performance.
> Which is all part of the larger 'meta' question...  What is the smallest
> set of modules that we see forming a useful runtime core?  Today, people
> can reuse our logging implementation even if they don't have an
> implementation of concurrent.  Should we relax that capability and
> assume that concurrent support is going to be universal?
> What is the smallest useful set of modules that we should declare are
> necessary for a runtime, so expect inter-module dependencies are ok; and
> which ones are always going to be optional/left behind in smaller
> runtimes? etc.
> Discuss :-)
> Tim

Tony Wu
China Software Development Lab, IBM

View raw message