Let’s Resync

Concurrency features in JDK 7

Brian Goetz
Sr. Staff Engineer, Sun Microsystems
[email protected]
This material is protected by
copyright and is licensed only for
use in connection with specific
presentations or training
engagements. For permission to
use, please contact
[email protected]
Overview

JDK 5.0 added lots of useful classes for coarse-grained

concurrency.
Now we need finer-grained concurrency, and JDK 7 adds
support for it.
Hardware trends
• As of ~2003, we stopped seeing increases in CPU clock rate
• Moore’s law has not been repealed!
• Getting more cores per chip rather
than faster cores
• Maybe even slower cores
• Chart at right shows clock speed
of Intel CPU releases
• Result: many more programmers
become concurrent programmers
(maybe reluctantly)

Copyright © 2007 Brian Goetz

Hardware trends
• “The free lunch is over”
• For years, we had it easy – there was always a faster machine coming
out in a few months
• We can no longer just buy a new machine and have our program run
faster
• Even true of many so-called concurrent programs
• Challenge #1: decomposing your application into units of work
that can be executed concurrently
• Challenge #2: Continuing to meet challenge #1 as processor
counts increase
• Even so-called scalable programs often run into scaling limits just by
doubling the number of available CPUs

Copyright © 2007 Brian Goetz

Hardware trends
• The primary goal of using threads has always been to achieve
better CPU utilization
• But those hardware guys just keep raising the bar
• In the old days – only one CPU
• Threads were largely about asynchrony; utilization improved by
allowing CPU to do other work during I/O operations
• In recent days – handful (or a few handfuls) of cores
• Utilization target was largely coarse-grained parallelism
• Application-level requests made reasonable task boundaries
• Thread pools were a reasonable scheduling mechanism
• Soon – all the cores you can eat
• May not be enough concurrent user requests to keep CPUs busy
• Will need to dig deeper to find latent parallelism
Copyright © 2007 Brian Goetz
Hardware trends drive software trends
• Languages, libraries, and frameworks shape how we program
• All languages are Turing-complete, but…the programs we actually
write reflect the idioms of the languages and frameworks we use
• Hardware shapes language, library, and framework design
• The Java language had thread support from day 1, but really only
useful for expressing asynchrony, not concurrency
• Which was just about right for the hardware of the day
• When MP systems became cheaper, platform evolved better
library support for coarse-grained concurrency (JDK 5)
• Principal challenge was identifying reasonable task boundaries
• Library needs to evolve again to provide better support for fine-
grained parallelism
• Enter the fork-join framework

Copyright © 2007 Brian Goetz

Finding finer-grained parallelism
• User requests are often too coarse-grained a unit of work for
keeping many-core systems busy
• May not be enough concurrent requests
• Need to find parallelism within existing task boundaries
• Most promising candidate is sorting and searching
• Amenable to parallelization
• Sorting can be parallelized with merge sort
• Searching can be parallelized by searching sub-regions of the data
in parallel and then merging the results
• Can use available CPUs to improve response time
• May actually use more total CPU cycles, but less wall-clock time
• Response time may be more important than total CPU cost
• Human time is more expensive than computer time

Copyright © 2007 Brian Goetz

Finding finer-grained parallelism
• Example: stages in the life of a database query
• Parsing and analysis
• Plan selection (may evaluate many candidate plans)
• I/O (already reasonably parallelized)
• Post-processing (filtering, sorting, aggregation)
• SELECT first, last FROM names ORDER BY last, first
• SELECT SUM(amount) FROM orders
• SELECT student, AVG(grade) FROM tests GROUP BY student

• The plan selection and post-processing phases are CPU-

intensive and could be sped up with more parallelism

Copyright © 2007 Brian Goetz

Divide-and-conquer
• Divide-and-conquer breaks down a problem into subproblems,
solves the subproblems, and combines the result
• Example: merge sort
• Divide the data set into pieces
• Sort the pieces
• Merge the results
• Result is still O(n log n), but subproblems can be solved in parallel
• Can apply this process recursively, until subproblems are small
enough that a sequential solution would be faster
• Parallelizes well – subproblems operate on disjoint data
• Scales well – with enough data, can keep many CPUs busy

Copyright © 2007 Brian Goetz

Divide-and-conquer
• Divide-and-conquer algorithms take this general form
Result solve(Problem problem) {
if (problem.size < SEQUENTIAL_THRESHOLD)
return problem.solveSequentially();
else {
Result left, right;
INVOKE-IN-PARALLEL {
left = solve(problem.extractLeftHalf());
right = solve(problem.extractRightHalf());
}
return combine(left, right);
}
}

• The invoke-in-parallel step wait for both halves to complete

• Then perform the combination step

Copyright © 2007 Brian Goetz

Fork-join parallelism
• The key to implementing divide-and-conquer is the invoke-in-
parallel operation
• Create two or more new tasks (fork)
• Suspend the current task until the new tasks complete (join)
• Naïve implementation would create a new thread for each task
• Invoke Thread() constructor for the fork operation
• Thread.join() for the join operation
• Don’t actually want to do it this way
• Thread creation is expensive
• Requires O(log n) idle threads
• Of course, non-naïve implementations are possible
• Package java.util.concurrent.forkjoin in JDK 7 offers one
• For now, download package jsr166y from
http://gee.cs.oswego.edu/dl/concurrency-interest/index.html
Copyright © 2007 Brian Goetz
Fork-join example
• Problem: searching an array for the largest element
• Requires O(n) comparisons, but amenable to divide and conquer
class SelectMaxProblem {
private final int[] numbers;
private final int start, end, size;
public int solveSequentially() {
int max = Integer.MIN_VALUE;
for (int i=start; i<end; i++)
max = Math.max(max, numbers[i]);
return max;
}
public SelectMaxProblem subproblem(int subStart, subEnd) {
return new SelectMaxProblem(numbers, start+subStart,
start+subEnd);
}
}

• Implementation can avoid copying elements

• Different subproblems work on disjoint portions of the data
• Which also happen to have good cache locality
• Data copying can impose a significant cost
• In this case, data is read-only for the entirety of the operation
Copyright © 2007 Brian Goetz
Fork-join example
class MaxSolver extends RecursiveAction {
private final static int THRESHOLD;
private final SelectMaxProblem problem;
public int result;
protected void compute() {
if (problem.size < THRESHOLD)
result = problem.solveSequentially();
else {
int m = problem.size / 2;
MaxSolver left = new MaxSolver(problem.subproblem(0, m));
MaxSolver right = new MaxSolver(problem.subproblem(m, problem.size));
coInvoke(left, right);
result = Math.max(left.result, right.result);
}
}
}
ForkJoinPool pool = new ForkJoinPool(nThreads);
MaxSolver solver = new MaxSolver(problem);
pool.invoke(solver);
int result = solver.result;

• Example implements RecursiveAction

• RecursiveAction class for non-result-bearing actions
• The coInvoke() method creates two new tasks and waits for them
• ForkJoinPool is like an Executor, but optimized for fork-join tasks
• Waiting for other pool tasks risks thread-starvation deadlock in
standard executors
Copyright © 2007 Brian Goetz
Performance considerations
• The lower the task-management overhead, the lower the
sequential threshold can be set
• Given a sufficiently efficient implementation, fork-join offers a
portable way to express many parallel algorithms
• Code is independent of the execution topology
• Reasonably efficient for a wide range of CPU counts
• Library manages the parallelism
• Frequently no additional synchronization is required
• Still must set number of threads in fork-join pool
• Runtime.availableProcessors() is usually the best choice
• Larger numbers won’t hurt much
• Smaller numbers will limit parallelism
• Must also determine a reasonable sequential threshold
• Done by experimentation and profiling
• Mostly a matter of avoiding “way too big” and “way too small”
Copyright © 2007 Brian Goetz
Performance considerations
• Table shows speedup relative to sequential for various
platforms and thresholds for 500K run
• Pool size always equals number of HW threads
• No other differences across HW platforms
• Can’t expect perfect scaling, because framework and scheduling
introduce some overhead
• Results show reasonable speedups for wide range of threshold
• As long as you avoid “way too big” and “way too small”

Threshold=500k Threshold=50K Threshold=5K Threshold=500 Threshold=50

Pentium-4 HT (2) 1.0 1.07 1.02 .82 .2

Dual Xeon HT (4) .88 3.02 3.2 2.22 .43

8-way Opteron 1.0 5.29 5.73 4.53 2.03

(8)
8-core Niagara .98 10.46 17.21 15.34 6.49
(32)
Copyright © 2007 Brian Goetz
Under the hood
• Already discussed naïve implementation – use Thread
• Problem is it uses a lot of threads, and they mostly just wait around
• Executor is similarly a bad choice
• Likely deadlock if pool is bounded – standard thread pools are
designed for independent tasks
• Standard thread pools can have high contention for task queue and
other data structures when used with fine-grained tasks
• An ideal solution minimizes
• Context switch overhead between worker threads
• Have as many threads as hardware threads, and keep them busy
• Contention for data structures
• Avoid a common task queue

Copyright © 2007 Brian Goetz

Work stealing
• The fork-join framework is implemented using work-stealing
• Create a limited number of worker threads
• Each worker thread maintains a double-ended work queue (deque)
• (Uses an optimized implementation, not the standard JUC deques)
• When forking, worker pushes new task at the head of its deque
• When waiting or idle, worker pops a task off the head of its deque and
executes it instead of sleeping
• If worker’s deque is empty, steals an element off the tail of the deque
of another randomly chosen worker
• Reduces contention
• No contention ever for head
• No contention ever between head and tail access
• Almost never contention for tail
• Stealing is infrequent
• Because order is LIFO, when a thread steals, it generally steals a big
chunk, which will keep it from having to steal again for a while
Copyright © 2007 Brian Goetz
Work stealing
• When pool.invoke() is called, task is placed on a random deque
• That worker executes the task
• Usually just pushes two more tasks onto its deque – very fast
• Starts on one of the subtasks
• Soon some other worker steals the other top-level subtask
• Pretty soon, most of the forking is done, and the tasks are distributed
among the various work queues
• Now the workers start on the meaty (sequential) subtasks
• If work is unequally distributed, corrected via stealing
• Result: reasonable load balancing
• With no central coordination
• With little scheduling overhead
• With minimal synchronization costs
• Because synchronization is almost never contended
Copyright © 2007 Brian Goetz
Taking it up a level
• Can we reduce the amount of “boilerplate” code in fork-join
tasks?
• Decomposing into subproblems, choosing between recursive and
sequential execution, managing subtasks
• Would be nicer to specify parallel aggregate operations at a
higher abstraction level
• Enter ParallelArray
• The ParallelArray classes let you declaratively specify
aggregate operations on data arrays
• And uses fork-join to efficiently execute on the available hardware
• Versions for primitives and objects
• ParallelArray<T>, ParallelLongArray, etc
• Resembles a very restricted, in-memory, parallel DBMS
• Less powerful than LinQ, but designed for parallelization

Copyright © 2007 Brian Goetz

ParallelArray
• The ParallelArray API looks imperative, but is really declarative
class Student {
String name;
int graduationYear;
double gpa;
}
ParallelArray<Student> students
= ParallelArray.createUsingHandoff(studentsArray, forkJoinPool);
double highestGpa = students.withFilter(graduatesThisYear)
.withMapping(selectGpa)
.max();
Ops.Predicate<Student> graduatesThisYear = new Ops.Predicate<Student>() {
public boolean op(Student s) {
return s.graduationYear == Student.THIS_YEAR;
}
};
Ops.ObjectToDouble<Student> selectGpa = new Ops.ObjectToDouble<Student>() {
public double op(Student student) {
return student.gpa;
}
};

• The actual work isn’t done until the call to max()

• Other methods merely set up “query”
• Filtering and mapping calls just set up lightweight descriptors
Copyright © 2007 Brian Goetz
ParallelArray
• Basic operations supported by ParallelArray
• Filtering – select a subset of the elements
• Done with withFilter() in previous example
• Can specify multiple filters
• Binary search supported on sorted parallel arrays
• Application – do something for each selected element
• Done with apply() method
• Mapping – convert selected elements to another form
• Done with withMapping() in previous example
• Replacement – create a new ParallelArray by replacing each element
with another derived from it
• Sorting, running accumulation, a[i] + b[i]
• Summarization – combine all values into a single value
• Maxima, minima, sum, average
• General-purpose reduce() method
Copyright © 2007 Brian Goetz
ParallelArray
• Operations can combine multiple parallel ParallelArrays
• Compute min(a[i] + b[i] + c[i])
// a, b, and c are ParallelLongArrays
long minSum = a.withMapping(CommonOps.longAdder(), b)
.withMapping(CommonOps.longAdder(), c)
.min();

• There are some restrictions

• All filtering operations must precede all mapping operations

Copyright © 2007 Brian Goetz

Connection with closures
• One of the features being debated for JDK 7 is closures
• One goal of closures is to reduce redundant boilerplate code
• Ugliest part of ParallelArray is the helper methods like selectGpa()
• These go away with closures
double highestGpa = students
.withFilter( { Student s => (s.graduationYear == THIS_YEAR) } )
.withMapping( { Student s => s.gpa } )
.max();

• With closures, API would be written in terms of function types

instead of named types
• Ops.Predicate<T> becomes { T => boolean }

Copyright © 2007 Brian Goetz