[concurrency-interest] jsr166y.forkjoin API comments
Osvaldo Pinali Doederlein
osvaldo at visionnaire.com.br
Fri Jan 25 14:44:22 EST 2008
jason marshall escreveu:
> On Jan 25, 2008 7:05 AM, Osvaldo Pinali Doederlein
> <osvaldo at visionnaire.com.br <mailto: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.
No... when it comes to primitive types versus objects, sometimes we're
still in the 1950's. ;-) I remember somebody (Doug?) stating that this
optimized support for primitives make some programs several times faster
(4x+?). I think the only real solution would be an enhancement of
generics to support primitives. But for better or worse, Java didn't go
that way and it's not likely that this can/will be addressed in Java 7,
or in any future release.
> 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.
I also have that bad feeling... but it's mostly psychological, because
lots of types and methods are all the same, they don't require extra
learning, and they occupy a tiny footprint in the JRE. I wonder if a
customized composition of the javadocs could alleviate this problem.
> 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)?
In most areas, betting against compiler technology proved to be a bad
bet. But one notable exception is memory-intensive applications,
remarkably numeric-oriented ones, versus GC and "everything is an
object" purism. Today we have GCs so sophisticated and full of tricks
that only Java gurus can tune their JVMs to the max (the ergonomics
stuff is far from perfect yet), and still, we can observe large
disadvantage against well tuned C code in the really wicked scenarios.
Even if the GC behavior is perfect, you still have to face the fact that
an Integer or Double object is 2-3X bigger than a primitive int or
double. It sucks up much more space in main RAM and caches, and requires
much more bandwidth.
The Java platform developed a number of workarounds, like java.nio's
direct buffers (read: manual memory management that favors manipulation
of data as raw byte arrays - even worse that primitive arrays of
primitive types, and RTSJ (more manual memory mgmt). I wonder if
forkoind could integrate to these things in the future.
Osvaldo Pinali Doederlein Visionnaire Informática S/A
osvaldo at visionnaire.com.br http://www.visionnaire.com.br
Arquiteto de Tecnologia +55 (41) 337-1000 #223
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest