harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Wilson <jessewil...@google.com>
Subject Re: [classlib][modularity] Logging performance improvements (HARMONY-6362)
Date Tue, 27 Oct 2009 16:32:14 GMT
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
 - 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.

> 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.

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" ?
 - 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message