How the JVM Actually Works Transcript, AI Summary & Key Points

00:00 A Java program starts its life as human readable source code. But when we run it, a lot happens behind the scenes to turn the source code into raw hardware instructions. At the heart of this is the Java virtual machine or JVM. The JVM is the engine that loads Java byte code, manages memory, and optimizes execution on the fly. Let's walk through the journey of a Java program from source file to machine code.

00:23 Phase one, the build step. Before the JVM even starts up, we need to compile the code. The Java compiler takes the Java source files and transforms them intoclass files. These files contain two important components. First, they hold Java byte code. Java byteode is a platform independent instruction set specifically designed for the JVM. The same byte code can be handed to a JVM on Mac OS, Linux or Windows.

00:51 And that JVM turns it into instructions the local machine can execute. This is the foundation of Java's famous promise write once run anywhere. Second, the class files hold metadata. Metadata describes the classes along with their methods, access modifiers, and variable types. The bite code and metadata might stay as separate.class files. It might be bundled into a jar.

01:14 It might live inside a Java module. The packaging varies, but the JVM is still looking for the same thing. The bite code instructions and the metadata that describes them. Today's video is sponsored by Code Rabbit, the most installed AI app on GitHub and GitLab. These days, one AI generated poll request can touch a dozen unrelated things, and reviewing it means bouncing between tabs.

01:37 Code Rabbit's new review UI fixes that. It splits the diff into small related chunks you can take one at a time. Click any function and its definition pops up right there. Got a question about the change? Just ask and you get the answer without leaving the page. And it flags the critical stuff first so you cut the review time and bugs in half. Start a free 14-day trial.

02:02 Link in the description. Phase two, the class loader subsystem. When we start the application in its bite code form, the JVM doesn't load the entire application into memory at once. Instead, it usually loads classes as they're needed by the executing code. If a specific class is never used during a run, it may never be loaded. This lazy loading is handled by the class loader subsystem.

02:24 It follows a set of rules called the parent delegation model. When an application asks for a class, the application loader first delegates the request upward. The top level bootstrap class loader gets the first chance to load more Java classes like java.lang.object. If it can't find the class there, the request drops down to the platform class loader, which handles other Java and JDK platform classes.

02:48 Finally, if it's still not found, it reaches the application class loader, which loads the application code from the class path or module path. This parent first lookup helps protect the runtime and makes it harder for the application code to replace core Java classes with malicious versions. Phase three, linking and initialization. Once a class file is located and loaded, the JVM links it.

03:12 Linking has three distinct steps. The first step is verification. Here the JVM checks that the bite code is valid. It checks that the code won't corrupt the internal stack or attempt illegal type casting like pretending that an integer is an object reference. The second step is preparation. This is where the JVM allocates memory for any static fields and assigns them their default values.

03:37 For example, numeric types are set to zero and object references are set to null. The third step is resolution. Java byte code initially uses symbolic names to reference other classes and methods. The JVM resolves these symbolic names into direct runtime references it can use. Some references may be resolved during linking. Others may be resolved later when they're first used.

03:58 Then finally comes initialization. This is where those static fields get their actual values defined in the code. and any static initializer blocks are executed. Phase four, runtime data areas. As classes are loaded, linked, initialized, and methods begin to execute, the JVM keeps program state in a set of runtime data areas. The shared spaces are accessible by all threads.

04:24 There we have the heap and the method area. The heap is a large workspace where all objects live. Conceptually, the method area stores class level structures such as metadata, method information, static variables, and the runtime constant pool. In the per thread spaces, each thread gets its own dedicated memory. This includes the JVM stack. Every method call pushes a new stack frame to hold local variables and partial results.

04:49 Each thread also tracks its progress using a program counter register. When the thread is executing Java byte code, it points to the current JVM instruction. If Java crosses into native code through Java native interface, the thread may also use a dedicated native method stack. Phase five, the execution. Now the bite code has to actually run. But how does bite code actually become hardware execution?

05:15 The exact execution strategy depends on the JVM implementation. Most production JVMs, including hotspot, use a hybrid execution engine to balance speed and startup time. At startup, the interpreter reads bite code one instruction at a time and executes it instantly. This makes the application boot up fast because there's no delay waiting for compilation from by bite code to machine code, but interpretation is relatively slow.

05:38 To speed this up, the JVM constantly monitors the code's behavior while it runs. If a specific piece of code is executed frequently, the JVM flags it as a hot spot. The just in time compiler grabs the hot bite code and compiles it directly into native machine code optimized for the specific CPU and saves it to a code cache. The next time that method is called, the JVM can use the compiled version instead of interpreting it again.

06:06 While the program is running, objects are constantly being created or abandoned on the heap. When an object is no longer reachable from GC roots, it becomes eligible for collection. The garbage collector tracks down these unreachable objects and reclaims their memory later. This spares the developers from manual memory management. The trade-off is that garbage collection can introduce pauses or latency overhead depending on the collector and workload.

06:31 This makes latency sensitive programs harder to reason about. Behind a running Java program, all of these pieces are working together. This is the JVM in motion.