Join Us at JavaOne 2009

There are several languages that target bytecodes and the JVM™ machine as their new "assembler," including Scala, Clojure, Jython, JRuby, the JavaScript™ programming language/Rhino, and JPC. This session takes a quick look at how well these languages sit on a JVM machine, what their performance is, where it goes, and why.

Some of the results are surprising: Clojure's STM ran a complex concurrent problem with 600 parallel worker threads with perfect scaling on an Azul box without modification. Some of the results are less surprising: fixnum/bignum math ops take a substantial toll on the benefit of entirely transparent integer math, and a lack of tail-call optimization gives some languages fits. Some of the languages can get "to the metal," and sometimes performance takes a backseat to other concerns. This session, for non-Java™ platform JVM machine users, is a JVM machine's-eye-view of bytecodes, JITs, and code-gen and will give you insight into why a language is (or is not!) as fast as you might expect.

This is essentially the presentation the speaker gave at the JVM Language Summit, refreshed with more recent work from the major alternative-language players. You will get an understanding of how some of these languages get mapped to a JVM machine and the issues and performance costs associated with a "less than perfect" language fit.

Managing software performance used to be a relatively straightforward process. Uniprocessors were the norm, the number of cycles each instruction took to execute was known, and it was mostly a matter of measuring how many instructions you were executing per unit of work -- and then reducing that number. The world has changed: The cost of individual instructions varies by several orders of magnitude, depending on how close the data is to the CPU, and improvements in throughput depend on effective use of parallelism. But to design and analyze performant programs, we have to understand something about the underlying hardware and how that has changed in recent years.

For example, a cache miss may take hundreds of cycles and a cache hit only a fraction of a cycle. That two-orders-of-magnitude spread can make relatively small code changes with significant performance consequences; data indirection is more expensive than it looks. (Advances in compiler technology have mostly removed the costs associated with code indirection, but data inlining hasn't moved out of academia yet.) VMs have the opportunity to do aggressive data optimizations, such as hot-field/cold-field splitting, so this wheel may turn yet again.

This session provides an overview of the architecture of modern CPUs, how this has changed in recent years, and what the implications are for software development and performance management.

People write toy Java™ technology benchmarks all the time. Nearly always they "get it wrong" -- wrong in the sense that the code they write doesn't measure what they think it does. Oh, it measures something all right -- just not what they want. This session presents some common Java technology benchmarking pitfalls, demonstrating pieces of real, bad (and usually really bad) benchmarks, such as the following: SpecJVM98 209_db isn't a DB test; it's a bad string-sort test and indirectly a measure of the size of your TLBs and caches. SpecJAppServer2004 is a test of your DB and network speed, not your JVM™ machine. SpecJBB2000 isn't a middleware test; it's a perfect young-gen-only garbage collection test. The session goes through some of the steps any programmer would go through to make a canned program run fast -- that is, it shows you how benchmarks get "spammed."

The session is for any programmer who has tried to benchmark anything. It provides specific advice on how to benchmark, stumbling blocks to look out for, and real-world examples of how well-known benchmarks fail to actually measure what they intended to measure.