JVM: The Java Virtual Machine

A UPI app works on phones from many different companies, with different chips and screens. That works because every phone runs a layer that hides those differences from the app. The Java Virtual Machine is that layer for Java: a pretend computer, defined in software, that behaves the same everywhere. Your program talks only to this "virtual" machine, and the JVM talks to the real one.

Why "Virtual Machine"?

A real computer understands its processor's machine code: one kind for Intel and AMD chips (x86-64), another for Apple silicon and most phones (ARM). A program compiled for one doesn't run on the other.

The JVM is a machine defined in software. It has its own instruction set, bytecode, its own rules for memory, and its own way of calling methods. javac compiles your code for this imaginary machine. Then each real platform gets its own JVM that turns those bytecode instructions into work its processor can do.

Three Meanings of "JVM"

People use the word JVM in three slightly different ways, and interviewers like to check that you know them:

Because the specification is public, several companies have built their own JVMs, and the same .class file runs on all of them.

What the JVM Does for Your Program

One java Command, One JVM

Every time you type java Something, a new JVM process starts, runs that program, and ends when the program ends. Two programs running at the same time each get their own JVM, with their own memory. This program shows a few facts about the JVM instance that's running it:

public class ThisJvm {
    public static void main(String[] args) {
        long pid = ProcessHandle.current().pid();
        int cores = Runtime.getRuntime().availableProcessors();
        long maxHeapMb = Runtime.getRuntime().maxMemory() / (1024 * 1024);
        String vmName = System.getProperty("java.vm.name");
 
        System.out.println("Process ID: " + pid);
        System.out.println("CPU cores:  " + cores);
        System.out.println("Max heap:   " + maxHeapMb + " MB");
        System.out.println("JVM:        " + vmName);
    }
}

Process ID: 48213
CPU cores:  8
Max heap:   4096 MB
JVM:        OpenJDK 64-Bit Server VM

How it works

1. Line 3 gets the process ID that the operating system gave this JVM. Run it twice and you get two different numbers: two different JVMs.
2. Line 4 asks how many processor cores the JVM can use.
3. Line 5 asks for the maximum heap size: the most memory this JVM will use for objects. By default it's about a quarter of your computer's memory.
4. Line 6 prints the name of the JVM implementation.

Try it yourself: run it with a smaller heap: java -Xmx256m ThisJvm.java. What does the "Max heap" line show now?

Not Only Java

The JVM runs bytecode, not Java source code, so any language whose compiler produces bytecode can run on it:

They all share the JVM's garbage collector, JIT compiler and the Java class library, which is a big reason the JVM has lasted so long.

Common Mistakes

Thinking there's one JVM per computer. There's one per running program. Five Java programs open at once means five JVMs.

Thinking the JVM is part of the operating system. It's an ordinary program that comes with the JDK. The operating system sees it as just another process.

Thinking every JVM is HotSpot. HotSpot is the most common, but OpenJ9 and GraalVM are real alternatives. Your code doesn't change; performance and memory use can.

Practice

1. Easy: Run ThisJvm twice. Which lines stay the same and which change? Why?
2. Harder: Run it with -Xmx128m and with -Xmx1g. Then explain in one sentence what -Xmx controls.

Key Takeaways