The Java Virtual Machine (JVM) is a very sophisticated piece of engineering. This post collects a series of videos to help you get a sense of what the JVM does behind the scenes to achieve high performance. These video found on YouTube and Vimeo are presentation given by JVM engineers and Java experts.
If you get through these videos the following terms will make sense to you:
- happens before
- on stack replacement (OSR)
- monomorphic, bimorphic and megamorphic methods
- escape analysis
- method handles
- and much more…
In no specific order:
- Learn about JVM internals – what does the JVM do?
- JVM Mechanics
- A JVM Does That? (2011)
- A JVM Does That??? (2016)
- Advanced Topics in Programming Languages: The Java Memory Model
- An introduction to JVM performance
- JavaOne 2016 – HotSpot Under the Hood
- JVM dive for mere mortals
- Java 8 and JVM: what’s new in HotSpot?
- JVM Flags Bread Crumbs
Submit other videos
Learn about JVM internals – what does the JVM do?
In this video, Dr. Ian Rogers of Azul Systems is going to cover in detail what a Java Virtual Machine (JVM) is and what it does for your Java applications.
Ian will dive into the inner workings of the JVM and drill down into what compilers and garbage collectors do. In particular, you will learn about common optimizations, well established garbage collection algorithms, and what the current biggest challenge with Java scalability is today.
JVM Mechanics | Doug Hawkins @ SF Java Meetup
HotSpot promises to do wonders for us by Just-in-Time (JIT) compiling the “right” code for us, but how does it makes those decisions? And, perhaps more importantly, what happens when it’s wrong? In this talk, you’ll learn through running Java code how the JVM decides to compile your code and see firsthand some situations where the JVM may get it wrong and have to deoptimize.
A JVM Does That?
Google Tech Talk (more info below)
March 29, 2011
Presented by Cliff Click, Azul Systems.
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).
A JVM Does That??? by Dr Cliff Click
2016 version Intro:
I worked on the HotSpot JVM for nearly 15 years, and I’m still constantly amazed as to what goes on inside them. High quality GCs, compilers, uniform threading & memory models, a cost model for code, dynamic code loading, introspection & reflection, access to the OS & hardware resources, a huge pre-built library. Where did all these services come from? Why are they here… and more importantly: when do they fail? What are the limitations we live with in the JVM? What services would we like to have (but cant & here’s why)?
Cliff Click is the CTO of Neurensic, and before that the CTO and Co-Founder of h2o.ai, the makers of H2O an open source math and machine learning engine for Big Data. Cliff wrote his first compiler when he was 15 (Pascal to TRS Z-80!), although Cliff’s most famous compiler is the HotSpot Server Compiler (the Sea of Nodes IR). That compiler showed the world that JIT’d high quality code was possible, and was at least partially responsible for bringing Java into the mainstream. Cliff helped Azul Systems build an 864 core pure-Java mainframe that keeps GC pauses on 500Gb heaps to under 10ms, and worked on all aspects of that JVM. Cliff is invited to speak regularly at industry and academic conferences and has published many papers about Hot.
Advanced Topics in Programming Languages: The Java Memory Model
AN INTRODUCTION TO JVM PERFORMANCE
Writing software for a virtual machine allows developers to forget about machine code assembly, interrupts and processor caches. This makes Java a convenient language, but all too many developers see the JVM as a black box and are often unsure of how to optimize their code for performance. This unfortunately adds credence to the myth that Java is always outperformed by native languages. In this talk we’ll take a peek at the inner workings of the HotSpot Virtual Machine, its Just-In-Time Compiler and the interplay with a computer’s hardware. From this, we will understand the more common optimizations that a virtual machine applies to be better equipped to improve and to reason about a Java program’s performance, and how to correctly measure runtime!