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 Thu, 12 Nov 2009 10:47:55 GMT
On 10/Nov/2009 03:52, Nathan Beyer wrote:
> On Mon, Nov 9, 2009 at 4:31 PM, Jesse Wilson <jessewilson@google.com> wrote:
>> 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
>> details.
> If it's out there, they certainly haven't popped up to say anything.
> Over the past few years I've gotten less and less interested in
> asserting the loose coupling of the modules. At this point, I'd rather
> go for reducing the module count and go for some sort of non-milestone
> release.

I already mooted the point earlier this year,

There was general approval so if you want to take a crack at it, go ahead.


> I certainly think there are separations that should be
> maintained, but I think there are a few that could be rolled together
> without any real concern.
> - Pull in all of the java.util.* into LUNI
> - Pull annotation into LUNI
> - Consider pulling lang-management into LUNI (this one's tough because
> of jmx dependencies)
> - Pull AWT and Swing together
> - Pull nio-char into nio
> Honestly, at this point, I think the biggest strength of Harmony's
> Class Library is the separation of UI and non-UI stuff. A JVM +
> headless classlibrary is very attractive.
>> 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
>> BufferedOutputStream<http://android.git.kernel.org/?p=platform/dalvik.git;a=blob;f=libcore/luni/src/main/java/java/io/BufferedOutputStream.java;h=835d13f153b6d2baff48621a596aa531bf42fffb;hb=master>class,
>>  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.

View raw message