2008 JavaOne Conference

With multicore systems becoming the norm, every programmer is being forced to deal with multi-CPU memory atomicity bugs: data races. Data race bugs are some of the hardest bugs to find and fix, sometimes taking weeks on end to deal with, even for experts. There are very few tools to help here (and these are mostly just academic implementations, FindBugs being a rare exception). This session’s speakers are at the forefront of multicore Java™ technology-based systems and have to debug data races daily. They have a lot of hard-won experiences with finding and fixing such bugs, and they share them with you in this session.

Download the presentation: Debugging Data Races »

Nonblocking (NB) algorithms are something of a Holy Grail of concurrent programming--typically very fast, even under heavy load, they come with hard guarantees about forward progress. The downside is that they are very hard to get right. This session’s speakers have been working on writing some nonblocking utilities over the last year (open sourced on SourceForge in the high-scale-lib project) and have made some progress toward a coding style that can be used to build a variety of NB data structures: hash tables, sets, work queues, and bit vectors. These data structures scale much better than even the concurrent JDK™ software utilities while providing the same correctness guarantees. They usually have similar overheads at the low end while scaling incredibly well on high-end hardware.

The coding style is still very immature but shows clear promise. It stems from a handful of basic premises: You don’t hide payload during updates; any thread can complete (or ignore) any in-progress update; use flat arrays for quick access and broadest-possible striping; and use parallel, concurrent, incremental array copy. At the core is a simple state-machine description of the update logic.

Download the presentation: Toward a Coding Style for Scalable Nonblocking Data Structures »

This session examines specific considerations introduced by the recent availability of various concurrent (non-stop-the-world) garbage-collected environments. An overview of important modeling and tuning considerations unique to concurrent garbage collection (GC) specifically covers the delicate interplay between GC cycle time, object allocation rates, available free heap, and garbage collection policy.

The presentation discusses and explains relevant GC terminology and phrases common in concurrent and mostly concurrent GC, focusing on their effects and relationship to metrics such as heap size, real and effective live set size, and object allocation rates. These include concurrent and mostly concurrent marking, live set and card marking, generational operation, and compaction.

The session includes specific examples of concurrent GC behavior with a wide variety of heap sizes, live set sizes, and allocation rates. It demonstrates the sampling of behavior across a characterized range, from idle all the way to the “collapse” point of a certain configuration. It also shows results based on heap sizes and live set sizes from 1 Gbyte to 300 Gbytes as well as allocation rates from “idle” all the way up to 30 Gbytes per second.

Download the presentation: Performance Considerations in Concurrent Garbage-Collected Systems »

This session examines specific considerations introduced by the recent availability of various concurrent (non-stop-the-world) garbage-collected environments. An overview of important modeling and tuning considerations unique to concurrent garbage collection (GC) specifically covers the delicate interplay between GC cycle time, object allocation rates, available free heap, and garbage collection policy.

The presentation discusses and explains relevant GC terminology and phrases common in concurrent and mostly concurrent GC, focusing on their effects and relationship to metrics such as heap size, real and effective live set size, and object allocation rates. These include concurrent and mostly concurrent marking, live set and card marking, generational operation, and compaction.

The session includes specific examples of concurrent GC behavior with a wide variety of heap sizes, live set sizes, and allocation rates. It demonstrates the sampling of behavior across a characterized range, from idle all the way to the “collapse” point of a certain configuration. It also shows results based on heap sizes and live set sizes from 1 Gbyte to 300 Gbytes as well as allocation rates from “idle” all the way up to 30 Gbytes per second.

Download the presentation: Performance Considerations in Concurrent Garbage-Collected Systems »

Available core counts are going up, up, up! Intel is shipping quad-core chips; Sun’s Rock has (effectively) 64 CPUs and Azul’s hardware nearly a thousand cores. How do we use all those cores effectively? The JVM™ machine proper can directly make use of a small number of cores (JIT compilation, profiling), and garbage collection can use about 20 percent more cores than the application is using to make garbage--but this hardly gets us to four cores. Application servers and transactional—Java™ 2 Platform, Enterprise Edition (J2EE™ platform)/bean--applications scale well with thread pools to about 40 or 60 CPUs, and then internal locking starts to limit scaling. Unless your application, such as a data mining; risk analysis; or, heaven forbid, Fortran-style weather-prediction application has embarrassingly parallel data, how can you use more CPUs to get more performance? How do you debug the million-line concurrent program?

“Locking” paradigms (lock ranking, visual inspection) appear to be nearing the limits of program sizes that are understandable and maintainable. “Transactions,” the hot new academic solution to concurrent-programming woes, has its own unsolved issues (open nesting, “wait,” livelock, significant slowdowns without contention). Neither locks nor transactions provide compiler support for keeping the correct variables guarded by the correct synchronization, such as atomic sets. Application-specific programming, such as stream programming or graphics, is, well, application-specific. Tools (debuggers, static analyzers, profilers) and libraries (JDK™ software concurrent utilities) are necessary but not sufficient. Where is the general-purpose concurrent programming model? This session’s speaker claims that we need another revolution in thinking about programs.

Download the presentation: Challenges and Directions in the Multicore Era »