Draft j.u.c JEP

[Doug Lea]

I was reminded that we ought to submit a JEP to cover
the non-lambda-related additions to java.util.concurrent
targeted for JDK8. Below is a draft. Comments and suggestions
during the next week before I submit it would be welcome.

....

Title: java.util.concurrent additions and changes for JDK8
Author: Doug Lea
Organization: SUNY Oswego
Created: 2012/4/21
Type: Feature
State: Draft
Exposure: Open
Component: core/lib
Scope: SE
Discussion: core-libs-dev at openjdk.java.net
Template: 1.0


Summary
-------

In addition to features in support of lambdas, we plan inclusion for
OpenJDK8 of a few new classes and methods in java.util.concurrent, as
well as ongoing improvements of existing classes, all spurred by
experiences and suggestions of users of the java.util.concurrent
package.

Motivation
----------

The continual evolution of uses of concurrency and parallelism in
applications requires continual evolution in library support.


Description
-----------

A non-exhaustive list:

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 (LongAdder, DoubleAdder,
LongMaxUpdater, DoubleMaxUpdater) 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.

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 reconsideration of a "Fences" API,
Sequence Locks, and other related support that better enables
construction of STM (Software Transactional Memory) frameworks.
However, STM support per se is not a goal for JDK8.

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 OpenJDK. Sources and mailing
list discussions may be found by following links at:

Testing
-------

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


Risks and Assumptions
---------------------

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


Dependencies
-----------

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.

Impact
------

We aren't aware of any other impact on JDK8.