What Lies Beneath: A tour of the dark gritty underbelly of OpenJDK
OpenJDK is the premier open source Java implementation. The OpenJDK project provides the code used to build Red Hat’s Java releases for Fedora and RHEL and the Java releases used on most other Linux distributions. It also forms the basis of Oracle’s proprietary Java binary releases.
The Red Hat OpenJDK team has been working for some time now, along with organizations like the London Java Community (LJC) and some of our academic partners (e.g. Glasgow & Manchester) to encourage researchers and developers to dive into the innards of OpenJDK’s Java Virtual Machine (JVM) and see how it actually works. One reason is the entirely selfish one that we would like to enlarge the community of potential contributors to the OpenJDK project. Another is that we think it is no bad thing for Java developers, as indeed for any developers, to understand the tools they are using at a deeper level and appreciate how a well designed tool shields them from having to manage some of the more complex aspects of the runtime environment in which their programs execute.
Earlier this year I gave a talk at FOSDEM describing some of the amazing things that go on under the hood inside Hotspot, the OpenJDK JVM. I subsequently repeated it for the benefit of the London Java Community and they have posted a video recording of that second talk. It’s a fairly deep dive (with Q&A it lasts 1hr 30 mins) and it explains the magic behind much of the pixie dust that makes OpenJDK run Java programs so efficiently. There’s quite a lot of technical detail but you don’t need to understand all (or even any) of that detail in order to get an idea of some of the clever things the JVM is capable of doing and why that adds up to making OpenJDK a race horse instead of a donkey. Enjoy!
N.B. The Q&A session at the end of the talk includes all the answers but the video did not cleanly capture the questions. So, here they are (prefaced with the relevant timestamp).
- (1:12:55) What else can cause a method to be deoptimised?
Auxiliary: (1:14:40) When else will cause the runtime to deoptimise a class?
- (1:18:40) How many calls must be made before a method gets compiled?
- (1:19:50) Why is it not usually a good idea to call System.gc?
- (1:22:59) How do you debug the code generated by the compiler?
- (1:24:56) How can you relate the generated machine code to the source code?
- (1:27:51) Is there a good reason not to set the compile threshold really low?
- (1:29:30) As a Java developer how does it help me to know all this?