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:53:28 GMT
On 10/Nov/2009 19:38, Jesse Wilson wrote:
> On Tue, Nov 10, 2009 at 1:47 AM, Mark Hindess
> <mark.hindess@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


Mime
View raw message