[concurrency-interest] ConcurrentHashMap footprint and contention improvements
dl at cs.oswego.edu
Tue Apr 12 20:07:17 EDT 2011
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
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
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")
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
which usually has better scalability with large numbers
of threads solely using get and put, but not otherwise
uniformly a better choice.
More information about the Concurrency-interest