The JVM Specification defines an abstract execution model, not an operating system memory map. An implementation may use JIT compilation, moving garbage collection, contiguous or segmented storage, and native metadata while preserving the specified behavior.
Runtime Data Areas #
Each JVM thread has a program-counter register, a JVM stack, and optionally a
native-method stack. The PC identifies the current JVM instruction for Java
code and has an undefined value while native code executes. A JVM stack holds
frames; failure to create a frame produces StackOverflowError for a size limit
or OutOfMemoryError when an expandable stack cannot grow.
The heap is shared and contains objects and arrays. The method area is shared and holds per-class structures; its concrete placement, such as HotSpot metaspace, is implementation-specific. Every class or interface has a runtime constant pool, the runtime form of its class-file constants and symbolic references. These shared areas are reached through class loading and are separate from a thread’s frames.
Frames and Execution #
Each method invocation creates a frame with a local-variable array, an operand
stack, a reference to the current class’s runtime constant pool, and return or
exception-completion state. Class-file max_locals and max_stack bound the
first two areas. Bytecode moves values between locals and the operand stack;
invocation instructions resolve symbolic references and transfer control to a
new frame. On normal completion a result is returned to the invoker’s operand
stack; on abrupt completion the VM searches exception handlers while unwinding.
Class loaders supply class-file bytes and establish type identity. The execution engine verifies, interprets, and may compile bytecode; it is not the class loader. The JVMS specifies their boundary in terms of loading, linking, initialization, and instruction execution rather than prescribing an engine architecture.
Boolean Values and Exit #
The JVM has no dedicated boolean arithmetic instructions. Java compilers use
int computational values for boolean expressions, and boolean arrays are
accessed with baload and bastore; the specification requires their stored
encoding to use 0 for false and 1 for true. Do not infer Java object-field
layout from bytecode conventions.
A Java application normally terminates when its last non-daemon thread ends.
System.exit requests VM termination through the runtime, while unrecovered
failure of one thread does not terminate other non-daemon threads. Native code,
shutdown hooks, and the host process can affect observed shutdown behavior.
Comments
Read or comment on GitHub (sign-in required to comment)