[concurrency-interest] MORE ON: Re[2]: RFC -- Java7 java.util.concurrent plans

Doug Lea dl at cs.oswego.edu
Thu Dec 11 12:29:24 EST 2008

Roman Elizarov wrote:
>  I would rather create
> a separate "AtomicArrays" class where compareAndSet, set, and get
> methods are declared for Object[], int[], and long[]. There will be
> analogy with "java.util.Arrays". It will be easy to learn and use just
> like "Arrays".

This might indeed be a better compromise. It would take some hard work
to make the reference version efficient -- it would need to
emulate ArrayStoreException checks at Java level, but in
a way that JVMs could subject to the usual machinations that
usually optimize them away. I'll look into it.

> It would be utterly cool for certain algorithms if this class also
> contains a method with the following signature:
>   void set(int[] a, int index, int value0, int value1);
> which atomically does:
>   a[index] = value0;
>   a[index+1] = value1;

Assuming you mean "int" only, you are probably better off manually
packing into longs. Most machines require 8byte alignment of
CAS/atomic-set of 64bit locations, which packing into longs would
automatically provide.

> now, the paired get for this would look ugly, so it might be a better
> aproach to pack the pair into long from the very start:
>   void setLittleEndian(int[] a, int index, long value);
>   void setBigEndian(int[] a, int index, long value);
>   long getLittleEndian(int[] a, int index);
>   long getBigEndian(int[] a, int index);

But this still doesn't force "long" alignment of even numbered
locations, which you'd need to ensure.

> This will close yet another Java vs native performance gap. Actually,
> there are only few places left where Java algorithm running on HotSpot
> significantly underperform compared to C/C++. One place is related to
> high-performance/concurrent data strucutures. Consider a hash map from
> int to Object. In C++ you would implement it as an array of structs.
> But in Java the only way to implement it is to have a separate int[]
> and a separate Object[]. Makes it twice as slow in practice, since
> there are twice as many cache rows to load. We badly need
> heterogenous/struct arrays. 

I completely agree. I've been arguing for this for years.
If anyone is looking for a good JVM project (on openJDK or elsewhere)
to sink a lot of time into, this is among the most needed for
supporting higher-performance data structures and algorithms
(not just parallel ones).


More information about the Concurrency-interest mailing list