• Type: JEP
    • Status: Completed
    • Priority: P4
    • Resolution: Unresolved
    • Fix Version/s: 8
    • Component/s: core-libs
    • Labels:
    • Author:
      Doug Lea
    • JEP Type:
    • Exposure:
    • Scope:
    • Discussion:
      core dash libs dash dev at openjdk dot java dot net
    • JEP Number:



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


      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.


      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


      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.

        Issue Links


          There are no comments yet on this issue.


            • Assignee:
              chegar Chris Hegarty
              dl Doug Lea
              Chris Hegarty
              Endorsed By:
              Brian Goetz
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: