[concurrency-interest] jsr166y.forkjoin API comments
jdmarshall at gmail.com
Fri Jan 25 12:17:28 EST 2008
On Jan 25, 2008 7:05 AM, Osvaldo Pinali Doederlein <
osvaldo at visionnaire.com.br> wrote:
> Having a subpackage of collections would look weird, first because it's
> different from tradition: today, common collections are in java.util(together with lots of other non-collection stuff), and all concurrent
> collections are in java.util.concurrent (together with with lots of other
> non-collection stuff). Not that I think that List and Locale belong in the
> same package; java.util is a messy bag of unrelated utilites, but that's a
> design that comes from JDK 1.0 - including the first general collections
> like Vector. But in a second argument, for more specialized packages like
> j.u.c and forkjoin, I think it makes sense to co-locate special
> collections with the APIs that are used together with them. Packages should
> reflect the tight coupling between these APIs.
I'm not sure I can agree with this. As a counterexample, I would cite more
complex APIs, which are split along functional areas. Swing is perhaps an
ad absurdum example of this, but there are more moderate ones, like XML or
the cryptography libraries. My main issue with the API so far, and the
reason Joe invited me to comment on it, relates to my strong negative
initial impression, which in a nutshell was this:
What the hell are these guys doing? Specialized primitive implementations?
You've got to be joking. It's not 1997, you know.
When I came to look at the ForkJoin code, I didn't expect the surface area
of the API to be so large. And when you pull up the Javadoc, the biggest
thing I notice is all of the Int-Int, Int-Long, Long-Int etc classes and
methods. It's too much. No, to be perfectly honest, it's a lttle shocking,
actually. And the only way to solve that problem, short of removing them
entirely, is to segregate the core of ForkJoin from the logical next steps
(practical and obvious implementations). So that when I look at the API
for the first time, I'm willing to give it a chance.
In other words, I should not have noticed the Array type specializations
first in an API. That's not what ForkJoin is, right?
Also, as a tangent back to my motivation for subscribing: I don't agree
that a 2x increase in performance (no actual numbers were cited, just
'noticeably faster') is worth all of this extra code. Haven't we learned by
now not to fight the JVM? Wouldn't a better solution be to figure out how
we can -help- the JVM optimize the code instead of trying to do the job for
it? And aren't the Number Objects allocated for the Object array likely to
have locality of reference anyway, because they will have temporal locality
(be allocated sequentially)?
> Notice that that tight coupling appears in the *interfaces*, not only in
> the implementations. For one thing, the Parallel*Array* classes are
> shock-full of methods that expose Ops.* interfaces in their signatures. This
> is very different, for example, from java.util.concurrent.atomic. The
> Atomic* objects are used massively in the *implementation* of classes from
> the entire JSR166 APIs, but they do not appear as arguments, return values
> or super-types of anything. I think the same is true (or at least mostly
> true) for java.util.concurrent.lock.
> Osvaldo Pinali Doederlein Visionnaire Informática S/Aosvaldo at visionnaire.com.br http://www.visionnaire.com.br
> Arquiteto de Tecnologia +55 (41) 337-1000 #223
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest