Taken from: http://www.ibm.com/developerworks/cn/java/j-lo-jvm-perf/ The implementation of JVM includes Sun Hotspot, IBM J9, and Oracle JRockit Java heap and stack class loading subsystem: Load classes into the runtime data area using fully qualified class names (package name and class name, network loading also includes URL); Method area: The definition of all methods and static data for Class is stored here, like a table or array, allowing the program to find the corresponding method’s Java bytecode and static data during execution; Java heap: a persistent storage area for Java objects, where objects instantiated from classes are stored, and garbage collection is also carried out. If there is not enough space to accommodate all current objects, an Out of Memory exception will be thrown. Understanding Java heap and garbage collection is crucial for optimizing application performance; The created Java objects (including arrays, which are also a type of object) are allocated in the heap, and garbage collection objects are used to free up space; The most commonly set heap size parameter is - Xms, which sets the initial size of the heap; -Xmx， Set the maximum value of heap space; -Xmn， Set the space size for the younger generation; -Xmo， Setting the size of the old generation space Java stack: where the bytecode of Java methods is executed, the lifecycle of local variables in the methods is in the stack, and the size of the stack is a key point we need to consider. It directly determines the number of layers of method calls, which is particularly important for recursive programs. The JVMs we use are all based on the running mechanism of the Java stack, with one exception. The Dalvik virtual machine of Google’s mobile operating system Android is based on a register mechanism (although Dalvik supports Java language development, from the perspective of virtual machines, it does not comply with Java standards). For a comparison of stack and register mechanisms in virtual machine implementation, please refer to the paper “Virtual Machine Showdown: Stack Versus Register”; The stack is divided into operand stack, stack frame data, and local variable area. The local variables allocated in the method are in the stack, and each method call is allocated a stack frame in the stack For stack based Java virtual machines, the calling and execution of methods are accompanied by push and drop operations. Each thread has its own independent stack, which is managed by the virtual machine, but we should have a concept of its size. The size of a stack is a double-edged sword. If it is too small, it may lead to stack overflow, especially when there is recursion or large loops within the thread. If it is too large, it will affect the number of stacks that can be created. If it is a multi-threaded application, it will cause memory overflow. The maximum value of the Java stack can be set through - Xss, with a default value of 256K. Program counter: For stack based JVMs, this is almost the only register used to indicate which Java bytecode the current Java execution engine is executing, with pointers pointing to the bytecode in the method area; Local method stack: This is where Java calls the operating system’s local libraries to implement JNI (Java Native Interface); Execution engine: the heart of JVM, controlling the loading and parsing of Java bytecode; Local interface: connects the local method stack and operating system libraries. II The following example of a Java memory leak, pop1, can cause a memory leak in the public class stack{
private static final int MAXLEN = 10;
private Object stk[] = new Object[MAXLEN];
private int stkp = -1;

public void push(Object p) {
stk[++stkp] = p;
}

public Object pop1() {
return stk[stkp–];
}

public Object pop2() {
Object p = stk[stkp];
stk[stkp–] = null;
return p;
}
}