[concurrency-interest] MORE ON: Re: RFC -- Java7 java.util.concurrent plans
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
> 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