A JVM Does That?

Cliff Click explains the complex illusions a JVM maintains, including JIT compilation, dynamic class loading, deoptimization, and garbage collection.

Google Tech Talk (more info below) March 29, 2011 Presented by Cliff Click, Azul Systems. ABSTRACT Just what the heck is a JVM *supposed* to do? JVMs already provide a host of services. The 'J' part definitely slants the service selection and the 'V' part means that underneath the illusion there's a lot of really cruddy stuff. The success of these illusions has led to the real popularity of JVMs. In particular, JVMs are probably the most popular way to distribute ready-to-use GC technology to the masses, and the 2nd most popular way to distribute ready-to-use compilation technology (just behind "gcc" I'm guessing). Just what are these illusions? The illusion that bytecodes are fast and have a reasonable cost model : (machine code generation, profiling, JIT'ing). The illusion that you can quickly change the program at any time (dynamic class loading, deoptimization, re-JIT'ing). The illusion of infinite memory (Garbage Collection). The illusion of a consistent threading and memory model (the JMM, volatiles, locks). The illusion of quick time access (i.e. Intel's "rdtsc" is mostly useless for time). The illusion that these other illusions all work on all sorts of machines from cell phones to 1000-cpu mainframes (it's kinda sorta mostly true). But these are not enough! The People cry out for more illusions! The illusion of an Infinite Stack (tail recursion), the illusion that running-code-is-data (closures), the illusion that Integers are as cheap as 'ints' (autoboxing optimizations), or that BigIntegers are as cheap as 'ints' (tagged ints), the illusion that memory supports atomic update (software transactional memory), or the illusion that with enough hard work other language implementation experts can make a JVM run utterly different languages (invokedynamic). Meanwhile, JVM engineers labor under the illusion that they can maintain this giant piggy pile of code, and maybe even expand the provided services without it collapsing under it's own weight. Here's my take on what services could & should be provided by a JVM, what services probably belong to the next layer up (STMs, new concurrency models), and what services belong to the next layer down (fast time management, sane thread scheduling).