Before we parted ways in 2010, there was a flurry of activity on the Java zone, including two new podcasts with some of the more prominent thinkers in the Java community: Sacha Labourey and Venkat Subramaniam. If you haven't had a chance, you'll want to
developerWorks: Please tell us a bit about your professional life and interests.
Daniel Luo: I am a software engineer from the IBM China Software Development Lab. The mission of our team is to make IBM middleware run better on new hardware platforms, such as multicore systems. Together with the IBM Toronto lab, our team is optimizing IBM middleware performance on new IBM hardware platforms. We're also developing tools/libraries to ease the development of parallel software on multicore systems. I currently lead the development of IBM's Multicore Software Development Kit for Java. MulticoreSDK is a set of development and analysis tools that help developers write correct, scalable, multithreaded Java applications targeted for multicore systems.
Yarden Nir-Buchbinder: For the past 10 years I have been working on and around IBM's ConcurrentTesting tool. ConTest is particularly useful for testing scheduling scenarios for a given unit or system test. Without such a tool (sometimes called a noise maker) even a complex concurrent test will miss too many bugs. A noise maker gives the test much more power with very little effort. Several features of ConTest are incorporated into the IBM MulticoreSDK. Both tools are are invaluable for parallel programming on the Java platform.
dW:What are you working on these days, in terms of research interests or projects?
DL: I am currently working on the MulticoreSDK project, which provides a set of tools that developers can use to test, debug, and analyze Java applications targeted for multicore hardware systems. These tools are capable of analyzing concurrency related problems that arise due to memory and synchronization errors such as data race and deadlock. The MulticoreSDK also provides tools to do profiling of various kinds of Java lock contention.
I am also working on a static concurrency bug patterns detector for Java code. The tool scans Java source code or byte code to search for instances of concurrency bug patterns -- code idioms that are likely to be errors related to multithreading. Static analysis can be done once the coding is complete, without additional test cases. Finding Java concurrency bugs in the early stages of the software development lifecycle is helpful for improving productivity.
YNB: The ConTest team currently is working in collaboration with Daniel on research aimed at reducing false alarms from race detection. I'm also part of FITTEST, a project supported by the EU that is aimed at testing Future Internet applications. According to the project vision, Future Internet applications combine multiple semi-independent services that communicate with one another, and may be composed dynamically. One of the challenges of testing complex internet applications is timing, which is similar in some ways to the timing challenges of concurrent programming, and different in other ways. One bug pattern shared by concurrent applications and Future Internet applications is the race condition, where two subsystems "race" on a third service's resource. In another case timing could be an issue: such as if an application implicitly relied on a response time that the called service wasn't programmed to accomplish. In these and other scenarios Future Internet applications take the concurrency programming challenge to a new level.
dW: What are the biggest challenges, from your perspective, in Java programming for multicore systems?
YNB: The biggest challenge is to learn to "think in parallel"; currently no tool can replace this skill, and it must come with some practice. Having achieved that, there remains the challenge of programming correctly, and in that I include programming efficiently. Tools greatly help here, but only so much.
DL: Introducing parallelism into software is essential to fully utilizing hardware performance in the multicore era. Writing correct and scalable Java parallel/multithreaded software is truly difficult, however. It is easy to introduce new categories of errors in multithreaded programs, and these errors can manifest unpredictably, based on specific threads interleaving at runtime. Another challenge is writing code that effectively exploits multicore processor performance. Ultimately, it's very difficult to diagnose/debug parallel errors and develop high-performance parallel applications, so I consider that to be the biggest challenge.
dW: What five tools for should every Java developer doing parallel or concurrent programming have in their toolkit today?
- A concurrent unit test environment
- State-of-the-art race and deadlock potential detectors
- A multiple scheduling generator (aka "noise maker")
- A performance analysis tool with emphasis on concurrency
- A static analysis tool with concurrent bugs patterns detection capability.
Ed note: The MulticoreSDK incorporates the first four of these tools. A static analysis tool is currently included in Rational Software Analyzer.
dW:What's most exciting to you, personally and professionally, about this new era of computing we're entering?
DL: It seems likely that the multicore trend will continue for decades, and I won't be surprised to see a 1000-core CPU appear in the near future. From my perspective what is most exciting is twofold: On the hardware side, high-performance computing is not only the privilege of big companies/research centers anymore, which could encourage more innovation from individuals. On the software side, we have the opportunity to create new programming models for parallel software development -- including programming languages, runtimes, tools, and libraries -- that fully utilize multicore hardware. Some revolutionary programming models may appear and rock the industry, just like the Java platform made waves in 1995.
YNB: A new way of thinking -- in parallel -- has suggested itself to software developers. Up-front, it is more complex than sequential software development. It is still an open question to what extent the developer community is up to the challenge. Can any developer learn to do it well, with reasonable effort? Is it just, as some experts surmise, a question of introducing it early in the education of programmers? Time will tell. (And the time is near!)
The real excitement, from my point of view, is not in the effect on programs, but in the effect on humans minds. The minds of many individuals will be enriched with a new capability, a new way of thinking. And just like the skill of programming changes the way we sometimes think about things that are not programs -- albeit subtly -- so I believe that the skill of parallel programming may (subtly) change the way we think about and understand things beyond software programming. Phenomena that is susceptible to thinking in parallel includes the behavior of multiple people in a cafeteria, cars on a road, and then the most magical of all parallel processors: the human brain.
dW: Looking into the future of multicore systems, what's one emerging trend that Java developers should be thinking about now?
YNB: The topic of Software Transactional Memory has been creating a lot of buzz in the research world for several years. It promises to change -- yet again! -- the way we think about programming in parallel. More specifically, it promises to relieve developers of the burden of data protection. STM still has challenges to overcome to become widespread. But the developer with the keen eye for the next phase beyond the horizon is advised to watch where this wind is blowing.
DL: The Java platform allows threads to communicate through shared memory, which is a root cause of many parallel programming errors. Some emerging programming models seek to ease the burden of parallel programming, including Actor models expressed by Erlang, Scala Actors, and Kilim. Hybrid data parallel models such as Nvidia CUDA, OpenCL, Intel Ct/rapidMind, and the IBM x10 programming language are also attracting attention. While not yet popular compared to the mainstream models, I think these approaches will be more important in the near future.
Ed note: Concurrency expert Alex Miller discusses Actors and other emerging concurrency models in a recent introduction to GPars -- Groovy's Parallel System. He talks more about the future of concurrency in his two-part podcast interview with dW's Andrew Glover.
Happy New Year! I wish everyone a productive and innovative 2011.