2010

1. In many situations, the JDK concurrent collection framework was your fist choice except:

  • IBM machine
  • Window Azue
  • Other JDK vendor

2. Library wasn't common or portable when the high scalability or performance is required. You need better understand your mahcine or system.

3. Entry, key data structure defined in many collections, node allocation was already in guarded. So make sure not put the "new" operation inside the lock scope.

4. Keep using the latest version of JDK concurrent library as you can. They always keep tracing the best result offer for you.

5. Little trick can bring huge return, for instance:

    Do you know why synchronized hash map still better than hash table in some conditions? As HashMap use the "==" first then try "Equals", so that's reason why concurrent library provide ConcurrentHashMap than ConcurrentHashTable.

6. Please evaluate your requirement, read only, write only, read most write rarely, read and write almost equals. Then seek better solutions for you. Not blendly trust other person testing results. (Of course, you should suspect my results either )

7. JDK leverage CAS resolving the consistency of memory and it was the key break through for our concurrent programming toolkits. But it has limitations, so STM (Software Transaction Memory), HTM  (Hardware Transaction Memeory) will help you resolve the consistency in high concurrent env.

8. Do you consider the memory fragment after you leverage the collections especially you have large chunk of data put/get/remove and each item consume large memory size either? If true, please isolate key word and information storage. One interesting implemenation for your reference Clojure's persistence vector or map.

 

Any thoughts from you? Hope we can provide the long list for our future reference! That's my dream.

[Introduction]

Concurrent version of HashMap was laregely used in the multiple thread programming. But most of them based on JDK, how about other alternative?

Today we will compare Click Cliff version of NonBlockingHashMap vs JDK ConcurrentHashMap

 

[Lab Environment]

 

Laptop: Dell E6400

CPU: Intel Core 2  (with 2 core)

Memory: 4G DDR2

JDK: Sun JDK 1.6 u21

 

//Forget: add OS information

OS: Windows XP sp3

 

 

[Testing Senario]

 

start   16 threads currently write string (UUID), each thread will write 1000  numbers of string,into the underlying single queue instance, and at  them  same time start 16 threads  concurrently reading the string, each  thread will read 1000 numbers of  string,has been inserted from the same  underlying single queue instance.

 

I have tested 3 rounds for each version:

 

VersionRound 1
Round 2
Round 3

GetGetGet
JSR 166 ConcurrentHashMapAVG: 3440.396AVG: 5284.996AVG: 3259.3
Cliff NonBlockingHashMapAVG: 2935.274AVG: 3158.488AVG: 7471.13

PutPutPut
JSR 166 ConcurrentHashMapAVG: 36421688.57AVG: 11300718.2AVG: 8250990.84
Cliff NonBlockingHashMapAVG: 91931746.36AVG: 63642538.64AVG: 57540781

 

Note: 

1. All the results was NanoSeconds.

2. Don't forget if running with JSR jar please add one JVM parameters: "-Xbootclasspath/p:D:/tmp/distribution/lib/concurrent/jsr166.jar" and modify the path to yours.

3. As HashMap will pre-consume memory. So please remember add "-Xmx" JVM parameters.

 

[Summary]

1. JSR166 ConcurrentHashMap was comparatively better than Cliff NonBlockingHashMap in the system with little core cpu.

2. If you need most was read operation, you can try Cliff NonBlockingHashMap. As the scalability and performance of read was it's strength.

 

Very important part:

As the condition was limited, so I couldn't find the powerful machine (Like 16Core or more). So the comparision may not be fair to Cliff's implementation. And Windows Azul has it's build-in JVM. So the behavior will be changed if moved to their machines.

 

 

[Reference]

1. Doug Lea : http://gee.cs.oswego.edu/dl/concurrency-interest/

2. Bootclasspath: http://www.tedneward.com/files/Papers/BootClasspath/BootClasspath.pdf

3. JSR 166.jar: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166.jar

4. Cliff's blog:http://www.azulsystems.com/blogs/cliff

5. Cliff none-blocking collection project: http://sourceforge.net/projects/high-scale-lib/

[Introduction]

Everyone current only use JDK provided concurrent library as that can meet many situations. But if you need more scalable one, I think maybe Doug Lea maintained new version of concurrent library would be your first considerations.

 

Today we will compare two version LinkedBlockingQueue performance

 

[Lab Environment]

 

Laptop: Dell E6400

CPU: Intel Core 2  (with 2 core)

Memory: 4G DDR2

JDK: Sun JDK 1.6 u21

 

//Forget: add OS information

OS: Windows XP sp3

 

 

[Testing Senario]

 

start  16 threads currently write string (UUID), each thread will write 1000 numbers of string,into the underlying single queue instance, and at them  same time start 16 threads  concurrently reading the string, each thread will read 1000 numbers of  string,has been inserted from the same underlying single queue instance.

 

I have tested 3 rounds for each version:

 

VersionRound 1
Round 2
Round 3
GetGetGet
JSR 166 LinkedBlockingQueueAVG: 259435.8AVG: 209333.5AVG: 261711.1
JDK  LinkedBlockingQueueAVG: 805892.1AVG: 381774.3AVG: 477590.5
PutPutPut
JSR 166 LinkedBlockingQueueAVG: 47124513.2AVG: 94489344.8AVG: 289728496
JDK LinkedBlockingQueueAVG: 240820336.6AVG: 268540401AVG: 108976599

Note:  All the results was NanoSeconds. Don't forget if running with JSR jar please add one JVM parameters: "-Xbootclasspath/p:D:/tmp/distribution/lib/concurrent/jsr166.jar" and modify the path to yours.


[Summary]

If you do need high scalability for Queue implementation we think JSR 166 LinkedBlockingQueue will be first choice for you.

 

We think one important change had already made into LinkedBlockingQueue but still not includes with latest JDK 1.6 library.

"http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/LinkedBlockingQueue.java?view=log reversion 1.54

move value allocation outside the lock scope."

make the two versions behavior differently.

 

Next round we will compare Dr.Click Cliff LockFreeHashtable vs Doug Lea ConncurrentHashMap

 

 

[Reference]

1. Doug Lea : http://gee.cs.oswego.edu/dl/concurrency-interest/

2. Bootclasspath: http://www.tedneward.com/files/Papers/BootClasspath/BootClasspath.pdf

3. JSR 166.jar: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166.jar

 

[Introduction]

Recently we have done one scale backend messaging processing system. Underlying the thread/concurrent design need one Queue implementation. And I found one interest replacement one "Amino Project" "LockFreeBlockQueue". It mentioned this implementation outperformed than jdk "ConcurrentLinkedQueue".http://www.infoq.com/articles/scalable-java-components. So I think maybe it will help us improve the whole system performance. And this project was based one IBM jdk, so I migrated it to SUN jdk.

 

[Lab Environment]

 

Laptop: Dell E6410

CPU: Intel i5  (with 4 core)

Memory: 4G DDR3

JDK: Sun JDK 1.6 u18

 

//Edit: Forget add OS information

OS: windows XP sp3

 

 

[Testing Senario]

 

start 16 threads currently write string (UUID), each thread will write 200 numbers of string,into the underlying single queue instance, and at them same time start 16 threads concurrently reading the string, each thread will read 200 numbers of string,has been inserted from the same underlying single queue instance.

 

I have tested 5 rounds:

Version

Round1

Get

Round2

Get

Round3

Get

Round4

Get

Round5

Get

LinkedBlockingQueue(JDK)

Max: 97384444

Min:  1117

Avg: 249965.7841

Max: 87218068

Min:  1117

Avg: 310944.5438

Max: 78754143

Min:  1117

Avg: 243207.1484

Max: 79043007

Min:  1117

Avg: 225175.4475

Max: 79446969

Min:  1117

Avg: 185973.6063

LockFreeBlockQueue(Amnio)

Max:94351097

Min:1396

Avg:233762.4281

Max: 143679993

Min:  1117

Avg: 520364.2

Max: 87081459

Min:  1117

Avg: 99177.67844

Max: 79612632

Min:  1117

Avg: 223982.8916

Max: 90056697

Min:  1117

Avg: 280250.0991

 

Note: All the results was NanoSeconds. Only calculate the read operations rather than write operations. Later will add the write operation statistics.

 

[Summary]

Doug Lea had done pretty jobs on the LinkedBlockingQueue, it's performance was stable and could meet most kinds of situation even in high concurrent situations.


Amino project wasn't so bad from the performance testing. But it cannot tell have outporformed than the Sun JDK implementation. But I didn't test on the IBM jdk env, maybe the situation will be changed.

 

And one important change had already made into LinkedBlockingQueue but still not includes with latest JDK 1.6 library. 

http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/LinkedBlockingQueue.java?view=log reversion 1.54

move value allocation outside the lock scope.

 

Later we will testing the latest version of Doug lea

 

[Reference]

1. Doug Lea : http://gee.cs.oswego.edu/dl/concurrency-interest/

2. Amino Project: http://sourceforge.net/projects/amino-cbbs/files/cbbs/1.0/amino-java-src-1.0.tar.gz/download?use_mirror=jaist

Filter Blog

By date:
By tag: