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 Tue, 10 Nov 2009 19:38:01 GMT
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.

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