Understanding JVM Architecture: Class Loading, Bytecode Execution, and Memory Model

In C you can execute custom machine instructions by treating a string as a function pointer, for example:

typedef void (*FUNC)(int);
char *str = "your code";
FUNC f = (FUNC)str;
(*f)(0);

This demonstrates a primitive virtual machine that reads instructions from a file and runs them, leading to a discussion of the Java Virtual Machine (JVM) architecture.

The JVM loads bytecode through a ClassLoader , which reads class files that contain a magic number, version, constant pool, and various attributes. The constant pool holds literal constants (e.g., Integer, Long, String) and symbolic references (e.g., method descriptors).

Key attributes include Code (containing bytecode, stack depth, and exception tables), LineNumberTable , LocalVariableTable , SourceFile , Deprecated , and Synthetic . These describe how the JVM maps bytecode to source lines, local variables, and metadata.

Class loading follows the parent‑delegation model : a class loader first delegates the request to its parent, ensuring that core classes (e.g., java.lang.Integer ) are loaded by the bootstrap or extension loaders, preventing user‑defined classes from overriding them.

When a class is loaded, the JVM creates stack frames for method calls. Each frame contains an operand stack and a local‑variable array whose size is fixed at compile time. The JVM may perform optimizations such as “stack‑frame tangling” to improve performance.

Method invocation can be static dispatch (determined at compile time) or dynamic dispatch (resolved at runtime via virtual method tables). The virtual method table stores the actual entry points for each method, allowing fast dynamic calls.

Execution proceeds in two phases: Java source is compiled to class files, then the JVM interprets or JIT‑compiles the bytecode. The HotSpot JIT has two compilers: C1 (client) for quick, reliable optimizations and C2 (server) for aggressive, long‑running optimizations. Background compilation can be disabled with -XX:BackgroundCompilation .

Escape analysis determines whether objects can be allocated on the stack, reducing GC pressure and eliminating unnecessary synchronization. Objects that do not escape a method can be stack‑allocated, omitted from heap allocation, or have their locks elided.

The Java Memory Model defines eight “happens‑before” rules that guarantee visibility and ordering of actions across threads. volatile variables provide immediate visibility and prevent instruction reordering, while other synchronization mechanisms ensure atomicity, visibility, and ordering.

Thread safety classifications include immutable, absolutely thread‑safe, relatively thread‑safe, thread‑compatible, and thread‑hostile. Synchronization techniques range from mutex locks to non‑blocking optimistic algorithms, with specialized locks such as spin locks, lightweight locks, and biased locks for performance tuning.

Overall, the JVM combines a rich class‑file format, sophisticated loading strategies, just‑in‑time compilation, and a well‑defined memory model to provide a portable and high‑performance execution environment for Java programs.