A few days ago, Brian Goetz came to visit a colleague of mine in our offices and I had the opportunity to hear some of the new concurrency features coming in JDK 7. We talked about the fork/join framework and Brian kindly showed us the presentation he gave at JavaOne.
The new fork/join model is a Java implementation of a parallel loop. It allows you to perform concurrent processing on relatively large amounts of data by distributing the load among different threads. So if your hardware platform has a lot of CPUs/cores you will be able to see significant performance improvement.
This is how it works: you create a number of tasks and you split the workload among them. Then you run all of your tasks concurrently using the coInvoke() method. Tasks are allocated to a pool of workers for processing. After all of your tasks have executed the coInvoke() method will terminate. This allows you to run many independant operations on a number of data.
Moreover the framework supports recursion, which means, that tasks can create and execute other tasks. This is very important because it allows you to parallelize practically any divide-et-impera algorithm. The example Brian has shown was Mergesort, but you are not limited to array data structures, you could for example do a BFS on a graph, or solve the maximum flow problem.
On top of the fork/join model a very useful parallel array data structure has been implemented that allows you to perform map, filter, sort and reduce operations. This is where things get interesting, because you start to express your application logic in terms of array operations.
The framework is nicely designed, smartly implemented and will be very useful with the forthcoming growth of the number of processor cores. But is this really the best framework available? There are several libraries for Java that already implement the worker farm model and moreover there are many languages that have native support for such things (HPJava, Fortran, Occam). Some libraries even go one level further and distribute the load on a cluster of machines (Map/Reduce, Hadoop).
What struck me most of all was that they didn’t integrate this parallelism in the language and the JVM. This was their most significant advantage over the existing solutions and they didn’t make use of it. It would have resulted in a much cleaner syntax and important optimizations could have been done at the JVM level. Maybe this will be a good testbed to something more radical in JDK8… or perhaps Scala?
PS: I apologize about some missing references, I’ll try to add these asap.