You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2009/11/10 10:47:47 UTC
Re: [classlib][modularity] Logging performance improvements (HARMONY-6362)
In message <a4...@mail.gmail.com>,
Jesse Wilson writes:
>
> 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.
Looking at the dlls/jars in this list:
http://www.webos-internals.org/wiki/WebOS_Doctor_version_1.1.0
it would seem that the Palm Pre uses harmony but does not include
concurrent or prefs.
Since they aren't active on the list I'm not sure how much we should let
this influence our decision. It does suggest that we should be cautious
about making assumptions about what downstream users might like to do.
I am reluctant to limit subsetting choices for (potential) downstream
users without good reason.
Regards,
-Mark.
Re: [classlib][modularity] Logging performance improvements (HARMONY-6362)
Posted by Tim Ellison <t....@gmail.com>.
On 10/Nov/2009 19:38, Jesse Wilson wrote:
> On Tue, Nov 10, 2009 at 1:47 AM, Mark Hindess
> <ma...@googlemail.com>wrote:
>
>> Since they aren't active on the list I'm not sure how much we should let
>> this influence our decision. It does suggest that we should be cautious
>> about making assumptions about what downstream users might like to do.
>> I am reluctant to limit subsetting choices for (potential) downstream
>> users without good reason.
>
> Well I guess the burden is on myself to provide a good reason! The
> java.util.concurrent package is excellent; it is Java's best API. By
> permitting its use by other modules, we will see increased correctness and
> performance...
>
> Consider java.net.NegativeCache. This class uses a global lock to interact
> with a LinkedHashMap concurrently. Upgrading to a more modern datastructure
> like a ConcurrentHashMap can improve application throughput. Similarly for
> the half dozen other caches in our code.
>
> Or perhaps InetAddress.isReachableByMultiThread(), which currently ignores
> InterruptedExceptions while its background thread is working.
>
> And there's SystemProcess, whose create() method contains 4 synchronized
> blocks. Perhaps this could benefit from java.util.concurrent? As it's
> written currently, an OutOfMemoryError while allocating one of the three
> buffers will cause the create() call to hang indefinitely.
>
> Writing code in 2009 without java.util.concurrent is like writing code with
> your hand tied behind your back.
You *are* allowed to use your feet too though.
Tim
Re: [classlib][modularity] Logging performance improvements
(HARMONY-6362)
Posted by Jesse Wilson <je...@google.com>.
On Tue, Nov 10, 2009 at 1:47 AM, Mark Hindess
<ma...@googlemail.com>wrote:
> Since they aren't active on the list I'm not sure how much we should let
> this influence our decision. It does suggest that we should be cautious
> about making assumptions about what downstream users might like to do.
> I am reluctant to limit subsetting choices for (potential) downstream
> users without good reason.
>
Well I guess the burden is on myself to provide a good reason! The
java.util.concurrent package is excellent; it is Java's best API. By
permitting its use by other modules, we will see increased correctness and
performance...
Consider java.net.NegativeCache. This class uses a global lock to interact
with a LinkedHashMap concurrently. Upgrading to a more modern datastructure
like a ConcurrentHashMap can improve application throughput. Similarly for
the half dozen other caches in our code.
Or perhaps InetAddress.isReachableByMultiThread(), which currently ignores
InterruptedExceptions while its background thread is working.
And there's SystemProcess, whose create() method contains 4 synchronized
blocks. Perhaps this could benefit from java.util.concurrent? As it's
written currently, an OutOfMemoryError while allocating one of the three
buffers will cause the create() call to hang indefinitely.
Writing code in 2009 without java.util.concurrent is like writing code with
your hand tied behind your back.