An explanation of the basic structure of the JVM and its parts (ii)

3.2 stack frame composed of operand stacks

The operand stack is one of the main contents of the stack frame, it is mainly used to save the intermediate results during the calculation, and also as the temporary storage space of variables in the calculation process.

The operand stack is also an advanced data structure that supports both the stack and the stack, and many Java bytecode instructions need to be passed through the operand stack. For example, the add command pops up two integers in the operand stack and calculates the addition, and the results are stacked, showing the changes of the Iadd stack before and after the operation.

3.3 Frame Data area

In addition to the local variables table and the operand stack, Java stack frames require some data to support constant pool parsing, normal method return, and exception handling. Most Java bytecode directives require constant pool access, and a pointer to the constant pool is maintained in the frame data area, making it easy for the program to access the constant pool.

In addition, when a function returns or an exception occurs, the virtual machine must restore the stack frame of the caller's function and let the caller function continue. For exception handling, the virtual machine must have an exception-handling table to find the code that handles the exception when an exception occurs, so the exception-handling table is an important part of the frame data area, and a typical exception-handling table looks like this:

Exception table:

From to target type

4 any

All

It indicates that a byte-code offset of 4--16 bytes may throw an arbitrary exception, and if an exception is thrown, jumps to the byte-code offset of 19 execution. When the method throws an exception, the virtual machine looks for a similar exception table to handle, and if the appropriate processing method cannot be found in the exception table, it ends the current function call, returns the calling function, throws the same exception in the calling function, and looks for the exception table of the calling function for processing.

3.4 Allocation on stack

On-Stack allocation is an optimization technique provided by the Java Virtual machine, and the basic idea is that for those objects that are private to the thread (this means objects that cannot be accessed by other threads), they can be scattered and allocated to the stack instead of being allocated to the heap. The benefit of allocating to the stack is that it can be destroyed at the end of a function call without the need for garbage collector intervention to improve the performance of the system.

A technical basis for stack allocation is the escape analysis, the purpose of which is to determine if the object's scope is likely to escape from the function body. A runaway object is shown in the following code:

private static User U;

public static void Alloc () {

u = new User ();

U.id = 5;

U.name = "Jim";

}

The object u is a member variable of a class that can be accessed by any thread and therefore belongs to a runaway object, and the following object shows a non-escaping object:

public static void Alloc () {

User U = new user ();

U.id = 5;

U.name = "Jim";

}

In the above code, the object user U exists in the form of a local variable, and the object is not returned by the Alloc () function or exposed in any form, so it does not escape, so it is possible for the virtual machine to allocate user u on the stack instead of on the heap.

For a large number of scattered small objects, on-stack allocation provides a good strategy for object allocation optimization, the stack is allocated fast, and can effectively avoid the negative effects of garbage collection. However, because the stack space is small compared to heap space, it is not suitable for large objects to be allocated on the stack.

Example 1: Test the allocation space location of non-escaping objects

Package COM.JVM;

public class Onstacktest {
public static Class user{
public int id = 0;
Public String name = "";
}

public static void Alloc () {
User U = new user ();
U.id = 5;
U.name = "Jim";
}

public static void Main (string[] args) {
Long B = System.currenttimemillis ();
for (int i=0;i<100000000;i++) {
Alloc ();
}
Long e = System.currenttimemillis ();
System.out.println (E-b);
}
}

To run the code using the-XMX10M-XX:+PRINTGC virtual machine parameter:

[GC (Allocation Failure) 2048k->544k (9728K), 0.0015011 secs]
10

The above code in the main function 100 million times alloc () call for object creation, because the user object instance needs to occupy about 16byte space, so the cumulative allocation space will reach 1.5G, if the heap space is less than this value, the GC will inevitably occur. At this point we only allocate the largest heap memory to 10M, if these objects are created on the heap, will inevitably cause a lot of garbage collection phenomenon, view garbage collection log, and not. Therefore, the description of its object is allocated on the stack.

Example 2: Compare the allocation space position of the test escape object:

Package COM.JVM;

public class Onstacktest {
public static Class user{
public int id = 0;
Public String name = "";
}
public static User U;
public static void Alloc () {
u = new User ();
U.id = 5;
U.name = "Jim";
}

public static void Main (string[] args) {
Long B = System.currenttimemillis ();
for (int i=0;i<100000000;i++) {
Alloc ();
}
Long e = System.currenttimemillis ();
System.out.println (E-b);
}
}

Also use the virtual machine parameter-XMX10M-XX:+PRINTGC to set the maximum heap space and print garbage collection logs to run this code:

Visible, a large number of garbage collection phenomenon, indicating that the heap memory is far from enough, the need for continuous garbage collection.

4 Method Area

Like a heap, a method area is a region of memory shared by all threads that holds the system's class information, such as fields, methods, Chang, and so on. The size of the method area determines how many classes the system can hold, and if the system defines too many classes, causing overflow in the method area, the virtual machine will also throw a memory overflow error.

In JDK1.6, JDK1.7, the method area can be understood as a permanent area (Perm). The permanent zone can be specified using Parameters-xx:permsize and-xx:maxpermsize, and by default,-xx:maxpermsize is 64M. A large permanent area can hold more class information. If the system uses some dynamic proxies, it is possible to generate a large number of classes at run time, and if so, you need to set a reasonable persistence size to ensure that no persistent memory overflow occurs.

In JDK1.8, the permanent zone has been completely removed, instead of the metadata area, the metadata area size can be specified using parameter-xx:maxmetaspacesize (a large metadata area allows the system to support more classes), which is a direct memory outside the heap. Unlike a permanent zone, if you do not specify a size, by default, the virtual opportunity runs out of all available system memory.

If an exception occurs in the metadata area, the virtual machine throws an exception.

An explanation of the basic structure of the JVM and its parts (ii)