editor's Blog

Preparing to Compute Using the Fork/Join Framework, Part 1

A couple weeks ago I figured out (more or less) what's wrong with Java threads. It's not that there's anything so wrong with Java threads per se -- it's just that they were designed to meet a need that is different from what developers face today: a world full of multicore processors powering everything from PCs to tablets to phones.

Now I'm working on converting a Java threads app that I developed a while back to utilize Java 7's new Fork/Join Framework. As the ForkBlur.java example illustrates, you can actually implement Fork/Join concurrency in a relatively small number of lines.

The fundamental component in the ForkBlur example is the ForkBlur class. Here's the key code that does the computation:

public class ForkBlur extends RecursiveAction {
  private int[] mSource;
  private int mStart;
  private int mLength;
  private int[] mDestination;
  
  private int mBlurWidth = 15; // Processing window size, should be odd.
  
  public ForkBlur(int[] src, int start, int length, int[] dst) {
    mSource = src;
    mStart = start;
    mLength = length;
    mDestination = dst;
  }

  // Average pixels from source, write results into destination.
  protected void computeDirectly() {
    int sidePixels = (mBlurWidth - 1) / 2;
    for (int index = mStart; index < mStart + mLength; index++) {
      // Calculate average.
      float rt = 0, gt = 0, bt = 0;
      for (int mi = -sidePixels; mi <= sidePixels; mi++) {
        int mindex = Math.min(Math.max(mi + index, 0), mSource.length - 1);
        int pixel = mSource[mindex];
        rt += (float)((pixel & 0x00ff0000) >> 16) / mBlurWidth;
        gt += (float)((pixel & 0x0000ff00) >>  8) / mBlurWidth;
        bt += (float)((pixel & 0x000000ff) >>  0) / mBlurWidth;
      }
      
      // Re-assemble destination pixel.
      int dpixel = (0xff000000     ) |
                   (((int)rt) << 16) |
                   (((int)gt) <<  8) |
                   (((int)bt) <<  0);
      mDestination[index] = dpixel;
    }
  }

  protected static int sThreshold = 10000;
  
  protected void compute() {
    if (mLength < sThreshold) {
      computeDirectly();
      return;
    }
    
    int split = mLength / 2;
    
    invokeAll(new ForkBlur(mSource, mStart,         split,           mDestination),
              new ForkBlur(mSource, mStart + split, mLength - split, mDestination));
  }

RecursiveAction is an abstract class that extends ForkJoinTask. Looking at the documentation for ForkJoinTask, you can see once again that standard Java threads are considered inadequate for the true parallel computational processing that modern multicore processors invite:

A ForkJoinTask is a thread-like entity that is much lighter weight than a normal thread. Huge numbers of tasks and subtasks may be hosted by a small number of actual threads in a ForkJoinPool...

In the code snippet, the computeDirectly() method is what performs the actual computations (in this case, a simplified method of blurring an image). You'll note that the input data is in the mSource array, the output is written to the mDestination array, and variables mStart and mLength define the locations within the array where the processing will occur. So, if mStart is set to 0 and mLength is set to the length of the array (i.e., the number of pixels in the image), you could call computeDirectly() and simply execute the blurring without parallel processing.

But, that's not what we want to do on our fancy N-core machine, right? We don't have time for that! Or, rather, our user doesn't... and we don't want them to switch to our competitor's app that takes full advantage of multicore processors, do we?

So, now let's look at the compute() method. This is indeed rather tiny:

  protected void compute() {
    if (mLength < sThreshold) {
      computeDirectly();
      return;
    }

    int split = mLength / 2;
    
    invokeAll(new ForkBlur(mSource, mStart,         split,           mDestination),
              new ForkBlur(mSource, mStart + split, mLength - split, mDestination));
  }

This says: if the current amount of the array to be processed is less than a threshold, call computeDirectly(); otherwise, divide the length to be processed in half, and utilize Java 5's invokeAll to execute the listed collection of tasks.

And what are the tasks we're going to execute if mLength was still larger than sThreshold? Two new ForkBlur() instantiations, one to process the first half of the array locations, the second to process the second half of the array locations. In other words, the work task is split into two tasks, each of half the size.

At this point you may be wondering: what about this sThreshold? How does that get selected? Do I just pull a value out of my hat? Call java.util.Random()?

This actually is one of my own primary questions regarding the Fork/Join Framework. If I have an N-core computer, I can divide a task into N equally-size pieces, launch N Java threads, and fully utilize my processor cores. So, if I'm utilizing the Fork/Join framework to do the same work, do I set a threshold value that accomplishes approximately the same thing? Or is that not the most efficient approach?

And, isn't it unreasonable to assume that a threshold value that optimizes performance on a particular device will also optimize performance on other devices that have different numbers of processing cores, different amounts of memory, etc. It doesn't seem like this threshold is going to be a "one-size-fits-all" proposition, to me...

This is definitely something I'll be researching as my experimentation continues.

Java.net Weblogs

Since my last blog post, several people have posted new java.net blogs:

• Rex Young, A little details about the implementation of Fast Messenger in JavaScript;
• Sonya Barry, JavaOne India;
• Fabrizio Giudici, Farewell to Java 6?; and
• Fabrizio Giudici, Understanding subtle new behaviours of JDK 7.

Poll

Our current Java.net poll asks Do you read Java Magazine?. Voting will be open until Friday, May 11.

Java News

Here are the stories we've recently featured in our Java news section:

• Baruch Sadogursky reports Artifactory 2.6 is released;
• Markus Eisele explains The Future of NoSQL with Java EE;
• John Yeary offers JSF 2 Tip of the Day: Learning the JSF Lifecycle with a PhaseListener;
• Jonathan Giles presents Introducing Scenic View;
• Hildeberto Mendonça demonstrates Integrating Jira with Netbeans;
• John Yeary offers JSF 2 Tip of the Day: Programmatic PhaseListener;
• Tori Wieldt announces Java Experts Present at JUG Meetings Across India;
• Geertjan Wielenga shares Sky Road Swap Trader;
• Craig Tataryn presents Episode 53 – Interview with Erkki Lindpere – Scala Sink or Swim;
• Armel Nene outlines 5 Things all Java developer should know when developing for the cloud;
• Cameron McKenzie asks Is it ever acceptable to make a Java Applet part of an enterprise wide rollout?;
• Geertjan Wielenga highlights CyBy2: Store & Visualize Chemical & Biological Data;

Spotlights

Our latest Java.net Spotlight is Neil Ghosh's JavaOne and Oracle Develope 2012 Hyderabad:

Like last year, JavaOne and Oracle Develop 2012 was organized and HICC on 3rd and 4th May 2012. The last time I attended such session was Tech Days when Oracle had just acquired Sun Miscrosystems. It was a two day program. This time the event was even larger...

Previously, we featured Tori Wieldt's JavaOne India Keynotes:

Over 2000 Indian developers were on hand to hear the opening keynotes at JavaOne in Hyderabad, India. The Nokia keynote provided an overview of the state of mobile technology and what it means for developers. The Java strategy keynote reminded the Indian Java community of the power and strength of Java and...

Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feed and the java.net blogs feed. You can find historical archives of what has appeared the front page of Java.net in the java.net home page archive.

-- Kevin Farnham

Twitter: @kevin_farnham

Brian Goetz Provides an Updated "State of the Lambda: Libraries Edition"

Recently, I've been investigating the methods Java provides for developing desktop applications that efficiently utilize multicore processors. Java 7's Fork/Join Framework is the current focus of my investigation. But, Brian Goetz has just provided an update on the State of the Lambda: Libraries Edition, which tells us lots about the current status of what's coming up in Java 8, where Project Lambda will introduce Lambda Expressions into Java.

It probably shouldn't be a big surprise, but implementing Lambda Expressions in Java 8 is going to have a very wide-ranging impact, on everything from the Collections framework to "laziness" to streams to parallelism to mutative operations... Brian takes the time to go into the details on these and other aspects of Lambda Expressions as the current work on Java 8 is progressing.

Brian states:

This document describes the design approach taken in the rough prototype that has been implemented in the Lambda Project repository. It is intended as a working straw-man proposal; the final version may look different, but there is a working design and implementation that may now serve as a jumping-off point for discussions.

If the implementation of Lambda Expressions in Java 8 is of considerable importance to you, this is a must read. The final implementation is no where near final at this point, and Brian is in essence asking people for suggestions. Take advantage of the offer to comment -- but, first, take the time to read Brian's State of the Lambda: Libraries Edition.

Java.net Weblogs

Since my last blog post, several people have posted new java.net blogs:

• Java.net Community Manager Sonya Barry, Site down for maintenance April 27-29;
• Rex Young, Fast Messenger Lite is released in Java and C#; and
• Bhakti Mehta, Session stickiness with Apache,mod_proxy and Glassfish.

Poll

Our current Java.net poll asks . Voting will be open until Friday, April 27.

Java News

Here are the stories we've recently featured in our Java news section:

• Jonathan Giles presents Interview with Peter Zhelezniakov;
• Fabien Duminy demonstrates Processing an HTTP response with the apache client;
• Dustin Marx demonstrates Improving On assertEquals with JUnit and Hamcrest;
• Ludovic Poitou attends Devoxx France, 1st Edition;
• Arun Gupta reports Expression Language 3.0 / JSR 341 Early Draft Now Available;
• Adam Bien shares A Great Set of Java EE Examples For Tomcat On Steroids (aka TomEE);
• Arun Gupta shares Great Indian Developer Summit 2012 Trip Report;
• Request from Geertjan Wielenga- Wanted: A Music Sheet Component in JavaFX!;
• John Clingan notes Java EE Brings Power to the POJO;

Spotlights

Our latest Java.net Spotlight is Arun Gupta's Chennai Java Summit 2012 Trip Report:

I attended my first Chennai Java Summit last weekend. The one-day conference had two parallel tracks. The conference was organized as part of AIOUG (All India Oracle User Group) and so there was a parallel track covering Oracle technologies as well...

Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feed and the java.net blogs feed. You can find historical archives of what has appeared the front page of Java.net in the java.net home page archive.

-- Kevin Farnham

Twitter: @kevin_farnham

Java 7 Fork/Join Framework Initial Look, and Resources

In some earlier posts, I've talked about Java threads, Java Thread Overhead, and Amdahl's Law and Parallel Processing Speed-Up. My next investigation in this series is Java 7's new Fork/Join Framework. I plan to spend quite a lot of time in this particular investigation. For one, Java Threads have been around for a long time, and undoubtedly there are many resources available that discuss them; but the Fork/Join Framework is new, and hence, by spending more time investigating the characteristics of the framework, I'll be helping to provide a roadmap or points for thought/discussion for other developers.

This first post is a basic introduction to the framework, pointing out some of the available resources, outlining the basic concept of the framework, etc.

So, to start with, what do the terms "fork" and "join" mean in this context? If you're a Unix/Linux programmer, you very likely know that the fork command creates a process that is duplicate of itself, known as a "child" process. From there, the two processes can work on different segments of a problem. The results of the processing of the separate segments of the problem can then be "joined" to produce the final product. This approach is advantageous if multiple processes can execute simultaneously, for example on a multiprocessor system like the 8-processor Sun servers I worked with starting in 1993, or on a modern dual- or quad-core desktop PC.

A kind of sad side note: the term "fork" is also used when a group of people takes an open source code base and begins separate development on that code. The same term is used, but unfortunately, in open source development there is no accompanying "join" that rebuilds the accumulated work from the original effort and the "forked" effort into a unified final product. In the open source world, a "fork" is the proverbial "fork in the road" wherein the path taken never reunites with the path foregone...

Anyway, Java 7's Fork/Join Framework is Unix/Linux-like in the manner in which it divies up work, then joins all the subcomponent results into a single unified result. The Fork/Join Tutorial states that:

The fork/join framework is distinct because it uses a work-stealing algorithm. Worker threads that run out of things to do can steal tasks from other threads that are still busy.

This reminds me of Intel's Threading Building Blocks (TBB), a C++ library for achieving parallel processing. I know a lot about TBB, since I was the original editor / community manager for open source TBB back in 2007-2008 when TBB was first open sourced. The "work-stealing" method has a long, and in my view successful, history as a method for making achieving efficient parallel processing that's not terribly taxing on the developer.

Julien Ponge agrees with me on the "not terribly taxing" statement in his OTN article Fork and Join: Java Can Excel at Painless Parallel Programming Too! Julien's article shows that:

rich primitives can be used and assembled to write high-performance programs that take advantage of multicore processors, all without having to deal with low-level manipulation of threads and shared state synchronization.

And, that last phrase is the key: dealing with low-level manipulation of threads and synchronization... If you've ever developed multithread applications in any of the older languages... Put it this way: coping with thread management is bad at the development level. Move to the test/debug level, and it becomes a nightmare. A real-life illustration from my own personal experience:

Big Boss: Your app is producing random results and crashing for our most important client!

Developer: I tested that thoroughly, completely, perfectly, all results were correct in the 18,476 tests I ran on our systems, and there were no crashes!

Big Boss: You're saying our most important customer is lying? Get yourself to their data center ASAP!

... At the customer's data center, the developer realizes the customer's computers are much more high-end than the ones he developed and tested the app on. There is a bug in the thread management, memory overwrites, something that happens on the customer's high-end computers that never happens on the computers on which the multithreaded software was developed and tested... whoa!

Developer (thinking): Now what do I do? Ask the customer if I can develop the fix using their operational system as my test bed? Won't that seem weird to them? But, do I dare do the obvious -- ask Big Boss to buy as high-end computers as our huge-business customer has? But, if miraculously he approved, then I'd have to spend weeks developing a test that simulates Big Customer's data analysis situation. Mightn't they decide to go with IBM's very expensive but proven solution before I can accomplish that???

Those with experience know: managing threads on your own isn't a pretty situation. I've done it, both in creating a custom data center (the safe way, since you can indeed test on the actual computers the software will run on), and in the blockquoted situation, where I was working for a software vendor, and what worked on our computers failed miserably on our big customer's much fancier more high-end systems...

Yes, I've been very deep in the thread trenches (since 1993!). Or, fallen very deep into the trenches? I consider myself a very good programmer, but dealing with native thread management? Please, at this point in my career, can't I just sit back and watch it all happen for me instead? Yeah, manage the threads for me, Fork/Join Framework. I'll take that!

Just to whet your appetite, here are a few more links to articles developers have written about the Fork/Join Framework:

• Ricardo Zuasti, An Introduction to the Fork / Join Framework
• Masoud Kalali, A walkthrough for the fork/join framework introduced in Java SE 7
• Fabrizio Chami, Java Fork/Join for Parallel Programming

I very much look forward to my upcoming experiments with Java 7's Fork/Join Framework. Stay tuned if this topic interests you!

Java.net Weblogs

Since my last blog post, several people have posted new java.net blogs:

• Mamadou Lamine Ba, If JAX-RS had an MVC framework?;
• Cay Horstmann, BOMed out by Notepad and javac;
• Jim Driscoll, A quick introduction to the Groovy language (part 2)
• Jim Driscoll, Executing Groovy Programs in-memory; and
• Alessandro Gentile, My new blog on java.net.

Poll

Our current Java.net poll asks How often do you attend Java conferences?. Voting will be open until Friday, April 20.

Java News

Here are the stories we've recently featured in our Java news section:

• Dustin Marx demonstrates Deleting All .class Files with Groovy;
• Jonathan Giles shares JavaFX links of the week, April 16;
• Tinuola Awopetu presents NetBeans Podcast #60;
• Arun Gupta promotes Concurrency Utilities for Java EE 6: JSR 236 Rebooting;
• Jean-Francois Arcand announces Atmosphere .9 .9 .9 .9 released: Tomcat/GlassFish WebSocket, Netty Framework, Hazelcast, Fluid API, JQuery Optimization;
• Dustin Marx asks Are Static Imports Becoming Increasingly Accepted in Java?;
• Chris Mayer reports Oracle proposes JDK8 Milestone and Release dates;
• Roger Brinkley presents Java Spotlight Episode 78: Jasper Potts on the JavaFX Scene Builder;
• Heather Van Cura announces Inactive JSRs looking for Spec Leads;
• Heather Van Cura announces Transparency call for Spec Leads and EC materials posted;
• Arun Gupta announces JPA and NoSQL using EclipseLink - MongoDB supported;
• Ludovic Poitou shares Tips: resource limits in OpenDJ;
• Niklas Schlimm presents Java 7 #8: NIO.2 File Channels on the test bench - Part 2 - Applying custom thread pools;
• Gunnar Hillert demonstrates how to Create Spring Integration Projects using STS;
• Jason Lee shares pointers for Java 7, NetBeans, Mac OS X, and a Little Bit of JavaFX 2;

Spotlights

Our latest Java.net Spotlight is Heather Van Cura's Recent JSR Updates-JSR 356, 357, 355, 349, 236 :

JSR 357, Social Media API, was not approved by the SE/EE EC to continue development in the JCP program. JSR 356, Java API for WebSocket, was approved by the SE/EE EC to continue development in the JCP program...

Previously, we featured Deepak Vohra's JSF 2.0 for the Cloud, Part One:

JavaServer Faces 2.0 provides features ideally suited for the virtualized computing resources of the cloud. Here, in Part One of a two-part article, we look at @ManagedBean annotation, implicit navigation, and resource handling...

Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feed and the java.net blogs feed. You can find historical archives of what has appeared the front page of Java.net in the java.net home page archive.

-- Kevin Farnham

Twitter: @kevin_farnham

JavaOne Call for Papers Ends Monday; Please Don't Wait Until the Last Moment!

It seems not that long ago that the JavaOne 2012 Call for Papers began. Yet, here we are, in the CfP's final weekend! All proposals for JavaOne 2012 sessions must be submitted by 11:59 PM Pacific Daylight Time (US) on Monday. Now, I'm not going to try to compute the equivalent local time for everyone around the world. In my experience, you don't try to submit something like this at the very last minute. What if your internet connection goes down, or a glitch occurs somewhere else? Getting your submission in well before early morning GMT on Tuesday is my advice.

Now, if only I can follow my own advice!

I'm proposing my first ever JavaOne session. We'll see what happens. My proposed session is related to the emergence of multicore desktop computers, tablets/pads, and mobile phones. I plan to go over the history of increases in processing speed, which reached a kind of limit some years ago. Once rapid increases in processing speed in a single processor core were no longer attainable, chip manufacturers started making multicore chips. So, the total processing power per chip continued to increase. But now, instead of the power increasing due to increased processing speed in a single core, the increased power came from multiple cores residing on a single chip.

This, of course, has major implications for applications. If your app is not multithreaded, it will use only one of the processor's cores. So, if someone has a quad-core device, your app will be using only one of those cores if it's not multithreaded. That's fine in some cases, for example for apps that have lots of interaction with the user. It's not fine if your app is computationally intensive. If your competitor develops an app that uses all available processors, their app will have blazing speed compared to yours. Not cool...

So, my proposed session will talk about this history, then get into the problems of multithreaded programming, from a generic, language-neutral viewpoint (remember, I was developing multithreaded apps in C and Fortran on SunOS systems in 1993). Problems like memory overwrites, deadlocks, threads that never complete... the world goes crazy once you get into parallel programming. So, what is "threadsafe" code anyway?

Next, my plan is to talk about the history of parallel processing in the JVM through today. Java has had threads for a very long time. It doesn't seem to me that many developers have actually used them. What was the need? For high-end data center processing, Java EE met the need. In the old single core processor world, what's the difference between a multiprocessor computer (like the 8-processor Sun machines I worked on in the mid 1990s) and a server farm?

But here's the problem: today, many people can pick up and hold in their hand what in the past was a mini data center, a mini server farm -- because, in their hand they can hold 2 or 4 or even 8 processor cores. Now, we're not going to use Java EE to make that fancy, powerful phone or tablet fully utilize all of its processing cores, are we? Well.. my friend Adam Bien might argue "why not?" since Java EE 6 provides such lightweight components.

He's right, Java EE could do the trick. But, the software that we want to utilize all the cores wasn't originally developed using Java EE. A great many of us are not inventing new apps; rather, we're trying to port existing apps into this new multicore world. Surely, we can't take the time to rewrite all that code such that it will efficiently run in a hand-held data center, can we? Does any company have a budget for that? Hence, the need for a path to convert desktop apps designed for operation on single-core processors into apps that can efficiently utilize the multicore processors that reside inside modern desktop computers, tablets, and mobile phones.

So, what about Java threads? I recently did some basic experimentation and found that, in a purely mathematical computational scenario, basic Java threads do a pretty good job of fully utilizing my CentOS Linux quad-core processor. But, basic Java threads don't work well in all scenarios. Hence, the decision to introduce the Fork/Join Framework in Java 7.

Converting existing apps developed for the single-core world is still an enormous amount of work, whether you convert the apps to use Java threads, the Fork/Join Framework, or even Java EE 6. This is what's behind the incredibly ambitious Project Lambda, which will introduce closures in Java 8. The parallelization will be implemented in the underlying Java libraries themselves, removing the need for desktop developers to deal with the damnable headaches associated with parallel programming (those memory overwrites, deadlocks, infinitely wandering threads, etc., that I mentioned above). The desktop app developer will simply have to invoke the underlying parallelism where doing so will increase performance. The complexities of thread management, etc., will all take place "under the hood."

If you can't wait for Java 8, and you're developing a new desktop app (whether your "desktop" is a PC, tablet, or fancy phone), there are multiple non-Java parallel programming options for the JVM that are available right now, in languages like Clojure and Scala.

I'll talk about all of this at JavaOne 2012, if my proposed session is accepted.

So, what do you think? Is this a session you might want to attend if you were at JavaOne 2012? Any suggestions on additional items I should include in my proposal? I have until Monday night to finalize it...

Java.net Weblogs

Since my last blog post, Rex Young posted two new java.net blogs:

• Rex Young, Direct addressing: revisiting the quick sort example; and
• Rex Young, Fast Messenger provides blocking calls through FutureReply.

Poll

Our current Java.net poll asks How often do you attend Java conferences?. Voting will be open until Friday, April 20.

Java News

Here are the stories we've recently featured in our Java news section:

• Geertjan Wielenga highlights Sharing A Stage: JDeveloper/ADF & NetBeans/Java EE 6?;
• Markus Eisele offers 5 Ways to Contribute to GlassFish without being a Programming Genius;
• Chris Smith asks Is Google Play the Beginning of the End for Android?;
• Arun Gupta investigates Tuning GlassFish for Production;
• Chris Mayer reports Introducing JavaFX Scene Builder - public beta unveiled;
• The Java Posse presents #382 - Roundup '12 Live Episode;
• Roger Brinkley presents Java Spotlight Episode 77: Donald Smith on the OpenJDK and Java;
• Neal Ford presents Functional thinking: Functional design patterns, Part 2;
• Carl Dea presents JavaFX links of the week, April 3;
• Geertjan Wielenga advises Update Your NetBeans Plugin's "Supported NetBeans Versions" In The Next Two Weeks!;
• John Yeary describes JSF 2.0 JQuery-JSF Integration; and
• Markus Eisele continues The Java EE 6 Example - Gracefully dealing with Errors in Galleria - Part 6.

Spotlights

Our latest Java.net Spotlight is Jonathan Giles's Interview with Jim Weaver and Stephen Chin:

Hi all. I’m currently sitting in a hotel room in Tokyo, but I’ve been waiting to publish this interview until Jim and Steve made their announcements this week. Now that the news of their employment at Oracle is out, here is the interview. Enjoy!...

Previously we featured Joseph D. Darcy's Goto for the Java Programming Language:

Work on JDK 8 is well-underway, but we thought this late-breaking JEP for another language change for the platform couldn't wait another day before being published. Title: Goto for the Java Programming Language...

Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feed and the java.net blogs feed. You can find historical archives of what has appeared the front page of Java.net in the java.net home page archive.

-- Kevin Farnham

Twitter: @kevin_farnham