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:44:36 GMT
On 09/Nov/2009 22:31, Jesse Wilson 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.

And I'd argue that the reason groups like Android /can/ pick up
alternative implementations is because we minimize the coupling between
the modules.

Maybe we need to make a finer distinction,

(a) non-API dependencies: so to take your example, if (say) LUNI had
links into the internal workings of Harmony's regex implementation there
would have been more places for you to hack the LUNI code to make it
work with your implementation of regex.  Minimizing the
non-(standard)-API dependencies is a good thing.

(b) API dependencies: some are placed upon us by the spec, and some are
quite bizzare or unfortunate.  So I the reason I need to have an Applet
implementation in order to compile our Beans implementation is because
there is a standard API dependency between them.  But without such
requirements it would be madness to have such gratuitous dependencies.

The knack is deciding which are gratuitous, and which are reasonable.
I'm happy to say that concurrent is common enough and a useful utility
that we can say 'go at it' to implement the other modules in terms of
concurrency APIs -- but if some bright spark wants to use the event
mechanism from Swing then I'd object.

(Not a fictitious example, there are plenty of examples of notionally
headless code that drag in this dependency.)

> Is anyone reusing modules from Harmony on a system that won't have a
> java.util.concurrent package? 

As Mark points out, yes there are apparently; but if they are not
prepared to come here and defend the argument then we get to make the
decisions for them <g>.

> I think it should be fair game for modules to depend upon the
> published APIs of other modules in their implementation details.

Within reason.

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

I assume you mean the I18N resource handling? in which case, yes, I
agree that is not such a bright idea.  There are people who take modules
(e.g. pack200) but not LUNI, I wouldn't mind if they had to copy the
resource handling code themselves to be self-sufficient.


View raw message