A Java Fork / Join Framework

Overall, this paper seems like a good approach to allowing programmers more access to tools for better multicore performance. As has been discussed several times already with hardware advances focusing more and more on additional cores for performance gain rather than clock speed it will become even more important for developers to work to make their software compatible with this architecture. Essentially extending a current library is a wonderful, non-disruptive way of accomplishing this since it allows those developers to better leverage the existing hardware without damaging their current code-base and practices.

But is this worthwhile? After all, we've read several papers already that discuss writing their own thread library, so clearly an interest exists for this. My intuition is that the addition of a new, better working threading library will not overwrite the reasons that many projects decide to construct their own. Projects that are highly concerned with efficiency will still be interested in getting every last tick of performance out of their machines and so will be looking at all levels of their architecture and technology stack for places they can improve, and if they feel the generic thread library (however advanced) is not enough, then they will construct their own much as they would now. And projects that are less concerned with efficiency will be glad that they have something that runs threads more efficiently, and move on to the next big advance (which we all hope is not Clippy 2.0). So it seems to me that much as now, writing your own thread library is a task that is highly dependent on the program itself and so would receive little benefit from this new technique, but as a general rule I would never turn down a more efficient library for general use.

I've worked a little bit with threads in Java before, and found them to be pretty easy to write (write well may be another story). And it seems from the code snippet and description that the author's framework maintains the same structure with the addition of isDone and join, which are both two sensible operations. So I can definitely see using this for large sequence number crunching or for set exploration, possibly even some image manipulation. But I feel that the greatest use of this sort of extension may never be visible even to most application programmers as this can be used to help increase the efficiency on a lot of backend systems and other libraries. I suppose I am also concerned about the possibility of developers attempting to "parallelize" their software for just the sake of saying it was done and attempt to apply this solution to anything they see as slowing them down even if the problem cannot be easily deconstructed into smaller subsets of itself.

On the plus side, it was nice to read a paper that actually had performance information analysis.