[concurrency-interest] ConcurrentHashMap footprint and contention improvements

Doug Lea dl at cs.oswego.edu
Fri Apr 15 20:08:39 EDT 2011


On 04/15/11 18:06, Benedict Elliott Smith wrote:
> If there is any interest and/or prospect of it being included in a future
> JDK, I will work on fleshing out the non-implemented methods ...

We are always looking for better implementations.
(The next plausible target for a major overhaul isn't
until JDK8 though.) So I encourage you and others to keep
exploring options. ConcurrentHashMap is is among the few
lock-based implementations in j.u.c. But so far we don't have
a non-blocking replacement that makes consistently better
tradeoffs across overhead, scalability, and footprint,
for all the API operations and contexts encountered by
developers.

Again, I do agree that bit-reversed sorting (Shalev-Shavit style)
is likely to be a good approach. Hitting those tradeoffs right
remains elusive, but something I hope to revisit sometime as well.

On 04/15/11 16:42, Rodrigo Kumpera wrote:
> For Marker-based list deletion it would be a matter of pushing JVM
> engineering to make AtomicMarkedReference usable.

Many people have pushed for a decade or so. It is a hard problem.
The GC and runtime folks do not like the idea of needing
to screen out mark bits on each pointer access. (And users
would not like the consequent slowdowns.) So markable pointers
would need to be segregated in some way to avoid this.
But the problem of how to segregate is almost as hard.

-Doug


More information about the Concurrency-interest mailing list