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 Mon, 09 Nov 2009 22:31:29 GMT
On Mon, Nov 9, 2009 at 4:14 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:

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

Using CopyOnWriteArrayList permitted me to strip off "synchronized" from
getHandlers(). This makes it possible for multiple threads to log messages
concurrently without contention.

The ability to consume modules from harmony without having to deal with
> inter-module spaghetti code is worth preserving.

Okay, I'll bite. Why is it worth preserving? We agree that it's useful for
projects to take some modules from Harmony and some from external sources.
Android gets most of its modules from Harmony, but has its own regex module.
But Android still *has* a regex module.

Is anyone reusing modules from Harmony on a system that won't have a
java.util.concurrent package? I think it should be fair game for modules to
depend upon the published APIs of other modules in their implementation

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.

In Android the luni module depends on our logging module! From our

 68 <#l68>     public BufferedOutputStream(OutputStream out) {
 69 <#l69>         super(out);
70 <#l70>         buf = new byte[8192];
 71 <#l71>
 72 <#l72>         // BEGIN android-added
 73 <#l73>         /*
74 <#l74>         * For Android, we want to discourage the use of this
constructor (with
 75 <#l75>         * its arguably too-large default), so we note its
use in the log. We
 76 <#l76>         * don't disable it, nor do we alter the default,
however, because we
 77 <#l77>         * still aim to behave compatibly, and the default
value, though not
 78 <#l78>          * documented, is established by convention.
 79 <#l79>          */
 80 <#l80>         Logger.global.info(
 81 <#l81>                "Default buffer size used in BufferedOutputStream " +
 82 <#l82>                 "constructor. It would be " +
 83 <#l83>                "better to be explicit if an 8k buffer is required.");
 84 <#l84>         // END android-added
 85 <#l85>     }

Java.util.logging provided a suitable vehicle for emitting a warning. We
haven't seen any problems caused by the coupling between luni and logging
modules. Now I'm not suggesting that we rush in to add coupling between
Harmony's modules, but I fail to see how the coupling is harmful. I also
think that the duplication in the resource bundling code is far worse than
the coupling it prevents.

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