JVM

In the chapter on compilation we learned that Java does not create fully formed native binary executables, but instead generates .class files which are used when executing a program. It was mentioned that these class files consisted of "bytecode" which would be fed into Java's runtime engine. We've been using this runtime engine constantly throughout this course, but we've not investigated exactly what it is. Now, we'll be taking a deep-ish dive into Java's runtime engine, the Java Virtual Machine (JVM).

This chapter relies heavily on information provided by the Java Virtual Machine Specification which I have hosted on this website for convenience.

Java began development as an object-oriented programming language that would act as a competitor to languages like C++. It initially focused on building software for networked consumer devices. This meant that code written in Java would ideally work on any platform that supported it, without the code itself needing to be targeted to fit platform-specific differences. Java's desire to be inherently cross-platform made it fundamentally distinct from C++, where code had to be compiled into an executable for a particular architecture before it is run. The idea can be visuallized as follows:

+----------+  +----------+  +----------+  +----------+
|  your    |  |  your    |  |  your    |  |  your    |
|  Java    |  |  Java    |  |  Java    |  |  Java    |
| program  |  | program  |  | program  |  | program  |
+----------+  +----------+  +----------+  +----------+
     |             |             |             |
+----------+  +----------+  +----------+  +----------+
|  Java    |  |  Java    |  |  Java    |  |  Java    |
| Platform |  | Platform |  | Platform |  | Platform |
| for      |  | for      |  | for your |  | for your |
| Linux    |  | Win32    |  |Television|  | Toaster  |
+----------+  +----------+  +----------+  +----------+
|  Linux   |  |PC Running|  |   Your   |  |  Your    |
|   Box    |  |Windows NT|  |Television|  | Toaster  |
+----------+  +----------+  +----------+  +----------+

As long as the Java program was written correctly in the first place, it should be capable of being run, without changes, on every single valid Java platform.

The Java ecosystem can be broken down into a few component parts:

• Java programming language
• Java class file format
• Java API
• Java Virtual Machine

Putting it all together we get:

     compile-time environment                           run-time environment
 - - - - - - - - - - - - - - - - -              - - - - - - - - - - - - - - - - -
|  Your program's source files    |            |  Your program's class files     |
|                                 |            |                                 |
|  +------+ +------+ +------+     |            |  +-------+ +-------+ +-------+  |
|  |A.java| |B.java| |C.java|     |            |  |A.class| |B.class| |C.class|  |
|  +------+ +------+ +------+     |            |  +-------+ +-------+ +-------+  |
|       |        |       |        |            |        \       |      /         |
|       +--------+-------+        | Your class |         v      v     v          |
|                |                | files move |       +---------------+         |
|                v                | locally or |       |     Java      |         |
|         +------------+          | through a  |       |    Virtual    |         |
|         |    Java    |          |  network   |       |    Machine    |         |
|         |  compiler  |          |            |       +---------------+         |
|         +------------+          |            |                ^                |
|                |                |            |                |                |
|                v                |            |  +------------+ +------------+  |
|  +-------+ +-------+ +-------+  |            |  |Object.class| |String.class|  |
|  |A.class| |B.class| |C.class|  |            |  +------------+ +------------+  |
|  +-------+ +-------+ +-------+  |            |      Java API's class files     |
|  Your program's class files     |            |                                 |
 - - - - - - - - - - - - - - - - -              - - - - - - - - - - - - - - - - -

We are particularly interested in the last link on the chain, the Java Virtual Machine, or JVM for short. Every single time we've invoked java to run one of our programs we've been spinning up a JVM! At base, the JVM is an abstract computing machine. It is abstract because it is not literally a machine, but a computational model that represents one. The JVM, much like a real computer, "has an instruction set and manipulates various memory areas at run time" (§ 1.2, JVM spec). The major advantage of a machine-independent computing engine is that the code that is written for it can completely ignore machine-specific details if desired.

Reflect on all of the code you have written so far for this course, have you ever written any code that specifically targetted x86_64 systems?

One thing about the JVM that might seem incredibly strange is it knows nothing about the Java programming language! The JVM has been developed to be a totally independent virtual machine. In fact, there have been many non-Java JVM-based languages created that make use of this reality—the most famous being kotlin, clojure, and scala.

The major "atomic" unit in the JVM is the class file. About ~280 pages of the JVM spec is dedicated to detailing the innerworkings of the class file structure and how it should be processed within a JVM. Each class file contains the definition of a single class, interface, or module. Class files are distinct from executables that are generated from compiling C or C++ insofar as they are meant to be loaded and executed by a JVM whereas C/C++ binaries are meant to run directly on the target machine.

Java belongs to the branch of languages called "managed runtime languages". This is because Java was built on the idea that it would be run in tandem with the JVM. Other languages that fit the bill would be Python, Lisp, Perl, Bash, etc. These languages are in direct contrast to "unmanaged runtime languages" like C, C++, Rust, etc. Managed runtime languages utilize powerful abstractions to separate the programmer as much as possible from low-level implementation details. For example, in this course we have never once seriously thought about how memory is freed up after we allocate it. This is a major benefit of Java and other managed runtime languages—the technique is called "garbage collection". We also get other goodies like runtime type-checking, array bounds checking, I/O exceptions, and much more. Not to mention the fact that Java has an incredibly robust "reflection" API that lets programmers manipulate and inspect types on the fly.

What we gain in functionality, we lose in speed. Unlike C++, and other unmanaged runtimes, there is massive overhead associated with running the JVM. Although it appears to be non-existant for our simple programs, it can really start to crop up on enterprise-level applications. JVMs have different ways of combatting this problem, but I will mention only one here: Just-in-Time compilation.

1. The chapter describes three distinct stages a Java program passes through before producing output: writing source code, compiling to bytecode, and executing on the JVM. For each of the following errors, identify which stage it would be caught at and explain why:
   • A missing semicolon at the end of a statement
   • A NullPointerException when calling a method on an uninitialized variable
   • Passing a String where an int is expected
   • Dividing by zero
   • Referencing a variable that was never declared
2. The chapter draws a distinction between the compile-time environment and the runtime environment. In your own words explain why these are two separate environments rather than one. What is the practical benefit of separating compilation from execution? Think about what this means for distributing a Java program to someone who uses a different operating system than you.
3. The chapter states that the JVM is responsible for executing bytecode regardless of the underlying hardware or operating system. In your own words explain what the JVM must know about the machine it is running on, and what it deliberately hides from your program. Why is it significant that the same .class file produced on a Linux machine can run on a Windows machine without recompilation? What would break this guarantee?
4. The chapter states that the bootstrap class loader returns null when queried in Java. Run the ClassLoaderDemo program from the chapter and observe the output. Why does Java represent the bootstrap loader as null rather than as a proper object? What does this tell you about the relationship between the bootstrap loader and the Java object system?
5. The chapter contrasts interpretation and JIT compilation as two strategies for executing bytecode. In your own words describe the tradeoff between the two. Under what circumstances would a pure interpreter be preferable to a JIT compiler? Under what circumstances would the reverse be true? Where does HotSpot's mixed-mode approach sit on this spectrum and why?
6. The chapter explains that Java's "write once, run anywhere" guarantee is made possible by the JVM acting as an intermediary between bytecode and the underlying hardware. Using the platform diagram from the chapter as a reference, explain what would have to be true of a new device (say, a smartwatch) for it to run Java programs. Who would be responsible for making that possible and what would they need to produce?
7. The chapter mentions that the bootstrap class loader loads java.base which contains classes like Object, String, and Thread. Consider what would happen if a programmer were able to replace the bootstrap loader's version of String with their own custom implementation. What could go wrong?
8. The chapter describes the JVM as an abstraction layer that hides the details of the underlying hardware. This is a recurring theme throughout the textbook — abstraction allowing programmers to work at a higher level without worrying about lower-level details. List three other abstractions you have encountered in this course and for each one identify what lower-level detail it is hiding from the programmer.