harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][modularity] Logging performance improvements (HARMONY-6362)
Date Mon, 09 Nov 2009 12:14:29 GMT
On 27/Oct/2009 16:32, Jesse Wilson wrote:
> On Tue, Oct 27, 2009 at 7:20 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> 
>> The improvement in performance is impressive.  What is the contribution
>> made by the use of the CopyOnWriteArrayList?
> 
> CopyOnWriteArrayList is ideal for situations when the following are all
> true:
>  - reads are frequent
>  - writes are rare
>  - reads and writes happen concurrently
> 
> This is exactly the scenario for logger's handlers. Each logged message
> results in a call to getHandlers() for the logger itself and for each of its
> parent loggers. The handlers list changes rarely: at startup only for
> typical apps. And it needs to be concurrent, because the logger API promises
> thread safety.

I didn't mean to ask "Why is a CopyOnWriteArrayList useful?", rather
what did it contribute to your logging improvements, e.g. correctness
that would require tons of duplicate coding otherwise, or performance
numbers, etc. (however, see below)

>> 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.
> 
> I don't think that the increased coupling really hurts us. Even if a project
> adopts only our logging module, such a project will presumably also have its
> own java.util.concurrent module.

It's that assumption that I want to ensure we are always thinking about.
 The ability to consume modules from harmony without having to deal with
inter-module spaghetti code is worth preserving.

>> 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.
>>
> 
> How do you feel about saying the core is "LUUUUUUUNI" ?

I'm prepared to accept that concurrent becomes part of the fundamental
core classes that are used to implement the remainder of the class
libraries.  I'd be less happy about seeing lots of references to, say,
logging scattered throughout the other modules.  We should remain modest
in our dependencies.

>  - lang
>  - util
>  - util.concurrent.*
>  - util.jar
>  - util.regex
>  - util.logging
>  - util.prefs
>  - util.zip
>  - net
>  - io
> This feels like a good fit to me, particularly since the RI exposes API
> interdependencies between these packages.

There's no accounting for bad design ;-}

Regards,
Tim


Mime
View raw message