JEP 155: Concurrency Updates

Summary

Scalable updatable variables, cache-oriented enhancements to the ConcurrentHashMap API, ForkJoinPool improvements, and additional Lock and Future classes.

Motivation

The continual evolution of uses of concurrency and parallelism in applications requires continual evolution in library support. All the work described here is spurred by experiences and suggestions of users of the java.util.concurrent package.

Description

1. Scalable updatable variables. Maintaining a single count, sum, etc., that is updated by possibly many threads is a common scalability problem. A small set of new classes (DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder) internally employ contention-reduction techniques that provide huge throughput improvements as compared to Atomic variables. This is made possible by relaxing atomicity guarantees in a way that is acceptable in most applications.

2. Added features (and possibly added APIs) that make ConcurrentHashMaps and classes built from them more useful as caches. These include methods to compute values for keys when they are not present, as well as improved support for scanning and possibly evicting entries, as well as better support for maps with large numbers of elements.

3. Added functionality and improved performance for ForkJoinPools that allow them to be used more effectively in the increasingly wider range of applications that users desire. New features include support for completion-based designs that are often most appropriate for IO-bound usages, among others.

Possible further additions include additional Lock and Future classes, and reconsideration of related support that better enables construction of STM (Software Transactional Memory) frameworks. However, STM support per se is not a goal for JDK 8.

Preliminary versions of these components (as well as other minor updates to others) have been, and continue to be, introduced outside of OpenJDK to solicit early feedback and experience reports (mainly by expert users) before integrating into JDK 8. Sources and mailing list discussions may be found by following links at http://gee.cs.oswego.edu/dl/concurrency-interest/index.html

Testing

We (the continuing set of JSR 166 members) provide functionality and performance tests for all components.

Risks and Assumptions

We assume that Oracle engineers will continue to assist integrating into JDK 8.

Dependences

Some features depend on lambda syntax and JDK declarations of common function types, so we will probably delay integration until we are more confident of their final form.