JEP 155: Concurrency Updates
|Discussion||core dash libs dash dev at openjdk dot java dot net|
|Funded-by||SUNY Oswego, Oracle|
Scalable updatable variables, cache-oriented enhancements to the
ForkJoinPool improvements, and, possibly,
Future classes and better support for software
transactional memory (STM) frameworks.
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
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 (
LongAdder) internally employ contention-reduction techniques that provide huge throughput improvements as compared to
Atomicvariables. 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
ConcurrentHashMapsand 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
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
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.
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.