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@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.
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@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.
On 04/21/12 13:10, Brian Goetz wrote:
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.
Tying this to a JMM revision is a little scary: We know there are bugs (ranging from typos to unintended semantics to incompleteness) in the JMM. None of them are very interesting wrt 99.99999% of all java programs. Still, the sense is that any revision should fix these as well. But some of these are not amenable to simple bandaids, but would require a major re-spec effort. In the mean time, we have introduced some methods (like AtomicX.lazySet) as well as those in the JDK7 Fences proposal that can ride on top of flawed underlying spec, in a way that doesn't introduce any further flaws, and so doesn't make eventual JMM re-spec any harder. When scoping out Fences for JDK7, I discussed the 3 minimal VM intrinsics methods to add with Hotspot and IBM J9 engineers. They were OK about doing it then (because it mainly entails just exposing some VM internals), so presumably still are, modulo scheduling effort to actually do it. The main questions are as always whether the potential benefits of exposing these methods to people who need them outweigh their relatively high potential for errors and uninterpretable effects. People have very strong view on both sides. (This doesn't impact us much inside java.util.concurrent because we can for the most part get the intended effects by directly using existing intrinsics.) Anyway, it's not clear we even want to have another discussion about introducing Fences. But I listed it because I think it is likely to come up again. -Doug
On 04/21/2012 09:50 PM, Doug Lea wrote:
On 04/21/12 13:10, Brian Goetz wrote:
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.
Tying this to a JMM revision is a little scary: We know there are bugs (ranging from typos to unintended semantics to incompleteness) in the JMM. None of them are very interesting wrt 99.99999% of all java programs. Still, the sense is that any revision should fix these as well. But some of these are not amenable to simple bandaids, but would require a major re-spec effort. In the mean time, we have introduced some methods (like AtomicX.lazySet) as well as those in the JDK7 Fences proposal that can ride on top of flawed underlying spec, in a way that doesn't introduce any further flaws, and so doesn't make eventual JMM re-spec any harder.
When scoping out Fences for JDK7, I discussed the 3 minimal VM intrinsics methods to add with Hotspot and IBM J9 engineers. They were OK about doing it then (because it mainly entails just exposing some VM internals), so presumably still are, modulo scheduling effort to actually do it.
The main questions are as always whether the potential benefits of exposing these methods to people who need them outweigh their relatively high potential for errors and uninterpretable effects. People have very strong view on both sides. (This doesn't impact us much inside java.util.concurrent because we can for the most part get the intended effects by directly using existing intrinsics.)
Anyway, it's not clear we even want to have another discussion about introducing Fences. But I listed it because I think it is likely to come up again.
-Doug
Given that fences is really low level, I'm not sure it's a good idea to have a public API for them. I would prefer to have a class sun.misc.Fences (or in sun.misc.Unsafe) i.e. a class that is part of the VM API but not part of the JDK API. Rémi
I would prefer that Fences was a JDK API rather than being "hidden" inside a VM one. It is low level but there's nothing unsafe about it in the sense of other APIs inside the Unsafe class, and it would be undesirable if one had to jump through hoops to get access to it like we do for Unsafe today (i.e. using reflection). Sent from my phone On Apr 22, 2012 6:02 AM, "Rémi Forax" <forax@univ-mlv.fr> wrote:
On 04/21/2012 09:50 PM, Doug Lea wrote:
On 04/21/12 13:10, Brian Goetz wrote:
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.
Tying this to a JMM revision is a little scary: We know there are bugs (ranging from typos to unintended semantics to incompleteness) in the JMM. None of them are very interesting wrt 99.99999% of all java programs. Still, the sense is that any revision should fix these as well. But some of these are not amenable to simple bandaids, but would require a major re-spec effort. In the mean time, we have introduced some methods (like AtomicX.lazySet) as well as those in the JDK7 Fences proposal that can ride on top of flawed underlying spec, in a way that doesn't introduce any further flaws, and so doesn't make eventual JMM re-spec any harder.
When scoping out Fences for JDK7, I discussed the 3 minimal VM intrinsics methods to add with Hotspot and IBM J9 engineers. They were OK about doing it then (because it mainly entails just exposing some VM internals), so presumably still are, modulo scheduling effort to actually do it.
The main questions are as always whether the potential benefits of exposing these methods to people who need them outweigh their relatively high potential for errors and uninterpretable effects. People have very strong view on both sides. (This doesn't impact us much inside java.util.concurrent because we can for the most part get the intended effects by directly using existing intrinsics.)
Anyway, it's not clear we even want to have another discussion about introducing Fences. But I listed it because I think it is likely to come up again.
-Doug
Given that fences is really low level, I'm not sure it's a good idea to have a public API for them. I would prefer to have a class sun.misc.Fences (or in sun.misc.Unsafe) i.e. a class that is part of the VM API but not part of the JDK API.
Rémi
participants (4)
-
Brian Goetz
-
Doug Lea
-
Rémi Forax
-
Vitaly Davidovich