Draft j.u.c JEP

[Brian Goetz]

This all looks great.

My only concern is the mention of a "fences" API; I would think that 
this might rise to the level of wanting its own JSR, since the memory 
model does not necessarily provide for the all various relaxed 
consistency modes that such an API would seem to imply, and might 
involve VM support.

On 4/21/2012 10:21 AM, Doug Lea wrote:
>
> 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.
>
>