Summary

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

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.

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.

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.