United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7036559 ConcurrentHashMap footprint and contention improvements
JDK-7036559 : ConcurrentHashMap footprint and contention improvements

Details
Type:
Enhancement
Submit Date:
2011-04-14
Status:
Closed
Updated Date:
2011-06-08
Project Name:
JDK
Resolved Date:
2011-06-08
Component:
core-libs
OS:
generic
Sub-Component:
java.util.concurrent
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:

Related Reports
Relates:
Relates:

Sub Tasks

Description
see discussion on core-libs-dev
  http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006511.html

-------- Original Message --------
Subject: [concurrency-interest] ConcurrentHashMap footprint and contention 
improvements
Date: Tue, 12 Apr 2011 20:07:17 -0400
From: Doug Lea <dl at cs.oswego.edu>
To: Concurrency-interest at cs.oswego.edu <Concurrency-interest at cs.oswego.edu>


For years, we've known that ConcurrentHashMaps have initial
footprints (over 1000 bytes using default constructor) that
are too big for casual use. And that the best way to address
this would be to use the Fences API to emulate "final field"
memory model guarantees in the presence of lazy initialization.
But we aren't releasing the Fences API. So I committed a version
that instead uses Unsafe calls to essentially the same effect
(reducing initial footprint to around 100 bytes, plus a few
percent savings for large populated tables). Also, this
version includes throughput improvements under contention
(mainly by interleaving locking with probes, to absorb cache misses),
which can double performance on big tables with many threads.
While conceptually straightforward, these lead to many
line-of-code changes.

The main price paid for these improvements is a greater reliance
of "volatile" vs "final" reads, which are essentially equivalent
in cost on most machines, but can be more costly on ARM and POWER.
Even on these though, the net effect should be positive.

It would be helpful if members of this list could help check
that this is so. The committed version is now
in java.util.concurrent sources (at
http://gee.cs.oswego.edu/dl/concurrency-interest/index.html)
and can be run by getting jsr166.jar and using
"java -Xbootclasspath/p:jsr166.jar" with any java7 build
or binary (http://dlc.sun.com.edgesuite.net/jdk7/binaries/index.html).
Also, as an alternative, I temporarily placed an unpackaged
source version (with the class renamed "CHM")
at http://gee.cs.oswego.edu/dl/wwwtmp/CHM.java
You can compile and somehow run in any java6/7 JVM.

While working on these changes, I also contemplated other
more extensive redesigns, including Cliff Click's non-blocking
version (http://sourceforge.net/projects/high-scale-lib/)
which usually has better scalability with large numbers
of threads solely using get and put, but not otherwise
uniformly a better choice.

-Doug

                                    

Comments
EVALUATION

see description.
                                     
2011-04-14
EVALUATION

Changeset: 005c0c85b0de
Author:    dl
Date:      2011-04-18 16:10 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/005c0c85b0de

7036559: ConcurrentHashMap footprint and contention improvements
Reviewed-by: chegar

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
                                     
2011-04-18



Hardware and Software, Engineered to Work Together