Doug Lea Discusses the Fork/Join Framework

"Doug Lea Discusses the Fork/Join Framework"

"...Part of this is that we have the luxury of building this framework on systems that have, for example, high performance, scalable, concurrent garbage collection, because garbage collection in these frameworks turns out to be an interesting issue. If you are implementing them, say in C, you generally have to slow down a lot of things in order to get the memory allocation right. In our case, we will spew lots of garbage, but it's very well behaved garbage and it's picked up by the garbage collector because it is unused 99% of the time."



"...We're also though, very conscious these days of building libraries for platform support. I think that there is upcoming support in Scala for nicer syntax, for automatically generating some of these recursive decompositions.
Clojure has been doing this for a while, X10 will be doing this - the IBM high performance language, Fortress in its current implementation uses our framework and several other research projects and experimental systems. We're providing fine-grained parallels and control for the languages that run on JVMs, rather than Java in particular, and that's really the way I think about this work - that I write it in Java on a VM because I can create very efficient algorithms."

"...but both the Clojure and Scala actor frameworks use the same engine with some different parameter settings than you would for parallel decomposition."

"...We have many, many requests for a concurrent cache, a variant of a concurrent hash map that has some sort of reclamation policy and discards and the like. We're not satisfied with any of our solutions, so we don't ship it."

"...I think everyone believes that every student - because we were talking about teaching - but every developer should have some understanding of coordinating asynchronous processes. ... It's not because you want to speed up, it's just that's the way the world is and you have to learn how to coordinate it. ...because the parallelism for the sake of speed up can be very easy."

"... The other aspect is intrinsically a little harder. When you have concurrency not really of your choosing, then usually it's less regular, you have to use more custom techniques. That is why we have a lot of these custom techniques in java.util.concurrent.So we have phasers and barriers and countdowns and a bunch of things that are all really good solutions to a class of problems, with no aspiration to universality."

"... We do think that there is a good strong chance that languages can evolve to make it so that - one of the buzzwords these days is deterministic parallelism."

"... It will take a year, off and on, to put out 500 lines of code, but we really hope that no one else does it."

"...We have more kinds of queues, for example, than most people ever want to know about and we apologize that it is a little confusing, as even worse, we're adding yet another one to Java 7.0. Queues of course are very central to the internals of concurrency, because when threads are waiting they are put in queues, when messages are being sent they are put in queues, when producers and consumers are exchanging data, they are put in queues."