# New Concurrency Features for Java SE 7

| by Geoffrey Wiseman 0 Followers on Jul 03, 2007. Estimated reading time: 4 minutes |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

JSR-166 helped bring Doug Lea's concurrency framework into Java Standard Edition 5. This work carried forward into Java SE 6 as jsr166x, which added a number of features to the Java collections framework for concurrency.

Although the contents of Java SE 7 are still in flux, early candidates for inclusion are are already taking shape in jsr166y: a fork/join framework and a transfer queue. InfoQ spoke with Doug Lea about these features and concurrency in Java SE 7.

The fork/join framework is a "multicore-friendly lightweight parallel framework" that supports a style of parallel programming where problems are recursively split into smaller fragments, solved in parallel and recombined, as described in this pseudocode from A Java Fork/Join Framework:

Result solve(Problem problem) {    if (problem is small)        directly solve problem    else {        split problem into independent parts        fork new subtasks to solve each part        join all subtasks        compose result from subresults    }}

This ensures that the work can be accomplished in parallel and works well on multi-core systems:

Big (32+) multicores will be coming out in volume during the lifetime of Java 7, and having this framework in place will allow people running them to get relatively simple speedups for computation-intensive tasks. Right now, forkjoin works best on machines like Sun Niagaras and Azuls, which are the only current processors of the form that will soon be common. It also works well on standard SMPs. In general, you don't get many speedup benefits with less than 4 processors though -- the main targets are in the dozens to hundreds of processors range.

Given a sufficiently-decomposed task size, the cost of executing the task may be exceeded by the cost of creating a thread. Accordingly, the fork/join framework uses thread pools which can be sized appropriately to the number of available cores to reduce the swapping overhead. To avoid straggling threads, the framework includes a work-stealing approach where a thread with no work can poach queued work from a slower-executing thread. The A Java Fork/Join Framework paper describes the mechanisms used by the fork/join framework and shows examples of performance in multicore systems and comparisons to other similiar kinds of parallel programming frameworks.

Describing the likely usage scenarios and adoption for the fork/join framework, Doug Lea said:

Overall, I expect an adoption curve vaguely similar to other concurrency utilities. At first only a few people who really need them will use them, but eventually, it will be hard to find programs that don't somehow rely on them, often buried deep inside infrastructure components. For this reason, surface syntax support might not be all that important anyway -- the kinds of library/component developers most likely to want to incorporate them are more likely to put up with awkward usage.

Ideally, there will be several layers of usages:

1. "Do this stuff in parallel" level, where a language or tools translates into parallel-ese, while also checking for safety/liveness. This is still partially in the realm of research though.

2. Arranging for parallel operations on collections. -- map, reduce, apply, etc. Programmers who can think about manipulating collections using aggregate all-at-once operations can use these to speed up common kinds of processing. (This is the ListTasks, ArrayTasks, etc layer.)

3. Hand-crafting an efficient forkjoin solution for a given problem. This is the layer I'm right now concentrating on, to be sure we can support the wide range of parallel algorithms possible using work-stealing frameworks. (Some of the currently odd-looking and under-explained methods like isQuiescent are designed for such advanced usages. Most programs just use "fork" and "join", but the others are there when you need them.)

4. Extending the framework to create new kinds of ForkJoinTasks etc. For example, those that operate transactionally. Only a very small number of people (for example, perhaps the Fortress runtime library developers) will ever need to do this, but there need to be enough base extension hooks to pull this off.

Another candidate for Java SE 7 is the TransferQueue. TransferQueue extends the BlockingQueue interface by adding producer-side blocking where the producer transfers an object to the consumer when both are ready. Non-blocking and timeout-style transfers are also available.
This is suitable for some kinds of message-passing applications where a hand-off can be necessary, and "to create a simpler-to-use thread pool, in which sometimes tasks must be synchronously transfered"

The transfer queue and fork/join framework may not be the only concurrency features added to Java SE 7. According to Doug Lea, there is an ongoing wishlist of new and request-for-enhancement features, including scalable counters, a ConcurrentIdentityHashMap, "additions to the atomics package to better support expert-mode fine-tuning of memory model effects" and algorithmic improvements to java.util.Collections.

The jsr166y effort builds on the work done in Java SE 6 as jsr166x, which brought new collections into Java SE6: Deque, BlockingDeque, NavigableSet, NavigableMap and ConcurrentNavigableMap (as well as the implementing classes, ArrayDeque, LinkedBlockingDeque, ConcurrentSkipListSet, ConcurrentSkipListMap and enhancements to TreeMap).

For more information on JSR-166, jsr166x and jsr166y, visit the Concurrency Interest site. InfoQ will keep you up to date as Java SE 7 progresses.

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

## Get the most out of the InfoQ experience.

### Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Cool stuff

This is pretty cool but this only really helps experts. The trick is going to be automatically making existing code run in parallel so that normal people can achieve the parallelization necessary. Dougs stuff is cool but I think is too low a level to shake the ground. That said, this will help more skilled people writing higher level libraries which decompose their tasks automatically using such an API. The higher level APIs/framework are whats needed to get most people writing heaviliy parallelized code without realizing they are doing it.

Exchanger 300x speedup

Brian Goetz mentioned that java.util.concurrent.Exchanger will see a 300x speedup in Java SE 7 at the NFJS Austin show this past weekend

Multi-core in a box or on a LAN?

Obviously the trend toward multiple cores on a single chip is huge. Modifying the VM to to advantage of that - and expose some of that functionality is important. But what about the current things like Tangosol Coherence? Would it be possible to adapt an approach like that - in essence running a VM per core?

While in some respects that would be a non-optimal solution - it could be advantageous to scale up and down the dedication of a multi-core system to running Java code. Spin up a couple of JVMs - say 4 to 8, and if you need more dedicate another 4 - 8 cores... When demand drops off, spin down the additional JVMs.

Additionally by pursuing a model which assumes that the JVMs/Cores are potentially non-local - it becomes easy to distribute processing across that rack of 32, 32-core servers.

Re: Multi-core in a box or on a LAN?

I'm thinking the same thing with ObjectGrid. Could a multicore wafer be organized as a grid? Intel recently demoed an 80 core wafer with high speed interconnects between cores. Its interesting to think if memory could also be part of a core, could something like ObjectGrid organized and handle bad cores within the wafer.

It would be nice also if these APIs were extendable to the distributed world as well as parallelism within a processor.

Re: Exchanger 300x speedup

Java 6 already gives a serious performance boost. Much of the concurrent code was rewritten to not use sync blocks as it a lot faster as a result even if no extra function was added.

Re: Multi-core in a box or on a LAN?

I'm thinking the same thing with ObjectGrid. Could a multicore wafer be organized as a grid? Intel recently demoed an 80 core wafer with high speed interconnects between cores. Its interesting to think if memory could also be part of a core, could something like ObjectGrid organized and handle bad cores within the wafer.

It would be nice also if these APIs were extendable to the distributed world as well as parallelism within a processor.

This is going to require some more intelligence out of grid frameworks, too... You'll want to know which grid nodes are local on the memory bus vs. which are remote across the network. Any kind of HA replication will need to make sure it's going to a remote node, whereas if you're hooking into these type of language features for parallelization, you'll want to keep the distribution of work local and possibly pull the data used out of each individual heap and into a shared memory space.

Commons-collections

Very nice staff indeed. But we can start use some part of it right now, without waiting for Java 7. E.g. try to use Commons-collections, all functional-oriented staff, like map, reduce, select, concepts of closures and predicates. It's available since ages (it works on Java 1.4) and extracting iterations out of your code you will automatically benefit when commons-collection will use multithreading.

Re: Commons-collections

But we can start use some part of it right now, without waiting for Java 7. E.g. try to use Commons-collections, all functional-oriented staff, like map, reduce, select, concepts of closures and predicates. It's available since ages (it works on Java 1.4) and extracting iterations out of your code you will automatically benefit when commons-collection will use multithreading.

This doesn't make sense. "We can start use it right now........just use commons-collections, wait a few years and pray, and eventually you might benefit". Sure.

Uh, ... and what's new about that?

One of the reasons why ForkJoin is very thoroughly tested is that Scala is already using it for years.
And with parallel collections, even non-experts can benefit from it:
    Array(1,2,3,4,5,6)     map fibonacci //Sequential    Array(1,2,3,4,5,6).par map fibonacci //Parallel
Close

#### by

on

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

9 Discuss

Login to InfoQ to interact with what matters most to you.