Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Memory region Partition of JVM

2025-01-28 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Network Security >

Share

Shulou(Shulou.com)06/01 Report--

Friends who have learned the C language know that when dividing the memory area, the C compiler often divides the managed area into data segments and code segments, including heap, stack and static data areas. So how is memory divided in the Java language?

Because the Java program is executed by JVM, when we talk about Java memory region partition, we actually mean JVM memory region partition. Before discussing the partition of JVM memory regions, let's take a look at the specific execution of the Java program:

As shown in the figure above, first the Java source code file (.java suffix) is compiled into bytecode files (.class suffix) by the Java compiler, and then the bytecode files of each class are loaded by the class loader in JVM. After loading, it is handed over to the JVM execution engine to execute. In the whole process of program execution, JVM will use a space to store the data and related information needed during program execution, which is generally called Runtime Data Area (runtime data area), which is what we often call JVM memory. Therefore, the memory management we often talk about in Java is to manage this space (how to allocate and reclaim memory space).

Now that we know what JVM memory is, let's discuss how this space is divided into regions, and whether there are stacks and heaps as in C language.

one。 What are the parts of the runtime data area?

According to the Java virtual machine specification, the runtime data area usually includes these parts: program counter (Program Counter Register), Java stack (VM Stack), local method stack (Native Method Stack), method area (Method Area), heap (Heap).

As shown in the figure above, the runtime data area in JVM should include these sections. Although it is stipulated in the JVM specification that the data area should include these parts when the program is running during execution, there is no provision on how to implement it, and different virtual machine manufacturers can have different ways of implementation.

two。 What data is stored in each part of the runtime datazone?

Let's take a look at which parts of the runtime data area are specifically used to store data during program execution.

1. Program counter

Program counters (Program Counter Register), also known as PC registers. Friends who must have studied assembly language are no stranger to the concept of program counter. In assembly language, program counter refers to the register in CPU, which stores the address of the instruction currently executed by the program (or the address of the storage unit where the next instruction is saved). When CPU needs to execute the instruction, it needs to get the address of the storage unit where the instruction needs to be executed from the program counter. Then the instruction is obtained according to the obtained address, and after getting the instruction, the program counter automatically adds 1 or gets the address of the next instruction according to the transfer pointer, which is cycled until all the instructions are executed.

Although the program counter in JVM is not a physical conceptual CPU register like the program counter in assembly language, the function of program counter in JVM is logically equivalent to that in assembly language, that is to say, it is used to indicate which instruction to execute.

Because in JVM, multithreading obtains CPU execution time through thread switching in turn, therefore, at any specific moment, the kernel of a CPU will only execute instructions in one thread. Therefore, in order to enable each thread to restore the program execution position before the switch after thread switching, each thread needs its own independent program counter and cannot be interfered with each other. Otherwise, the normal execution order of the program will be affected. Therefore, it can be said that program counters are private to each thread.

In the JVM specification, if the thread is executing a non-native method, the address of the instruction that currently needs to be executed is stored in the program counter; if the thread is executing the native method, the value in the program counter is undefined.

Because the size of the space occupied by the data stored in the program counter does not change with the execution of the program, there is no memory overflow (OutOfMemory) for the program counter.

2.Java stack

The Java stack is also known as the virtual machine stack (Java Vitual Machine Stack), which is often referred to as the stack, similar to the stack in the data segment of the C language. In fact, the Java stack is the memory model for Java method execution. Why would you say that? Let's explain why.

The Java stack stores stack frames one by one, each corresponding to a called method, including local variables (Local Variables), Operand stack (Operand Stack), references to the class to which the current method belongs (Reference to runtime constant pool), method return addresses (Return Address), and some additional information. When a thread executes a method, it creates a corresponding stack frame and presses the established stack frame. When the method is executed, the stack frame is taken off the stack. Therefore, the stack frame corresponding to the method currently executed by the thread must be at the top of the Java stack. At this point, you should understand why it is easy to lead to stack memory overflow when using recursive methods, and why the space in the stack area is not managed by programmers (of course, in Java, programmers basically do not have to deal with memory allocation and release, because Java has its own garbage collection mechanism), the allocation and release of this part of the space are automatically implemented by the system. For all programming languages, this part of the stack space is opaque to programmers. The following figure shows a model of a Java stack:

The local variable scale, as its name implies, must not need to be explained. You should understand its function. It is used to store local variables in a method (including non-static variables declared in the method and function parameters). For variables of basic data types, their values are stored directly, and for variables of reference types, references to objects are stored. The size of the local variable table can be determined by the compiler, so the size of the local variable table will not change during program execution.

Operand stack, friends who must have studied the stack in the data structure must be familiar with the problem of expression evaluation. One of the most typical applications of the stack is to evaluate expressions. Think of the process in which a thread executes a method, which is actually the process of constantly executing statements and, in the final analysis, the process of calculation. Therefore, it can be said that all the calculations in the program are done with the help of the Operand stack.

A reference to the runtime pool, because constants in the class may be needed during method execution, so there must be a reference to the runtime constant.

Method returns the address, and when a method is executed, it returns to the place where it was called, so a method return address must be saved in the stack frame.

Because each thread may be executing differently, each thread has its own Java stack that does not interfere with each other.

3. Local method stack

The function and principle of the native method stack and Java stack are very similar. The only difference is that the Java stack serves to execute Java methods, while the local method stack serves to execute local methods (Native Method). In the JVM specification, there is no mandatory stipulation on the specific implementation method and data structure of the local development, and the virtual machine can realize it freely. The local method stack and the Java stack are directly combined into one in the HotSopt virtual machine.

4. Heap

In C language, the heap space is the only area of memory that programmers can manage. Programmers can request and free space on the heap through the malloc function and the free function. So what's it like in Java?

The heap in Java is used to store the object itself and the array (of course, array references are stored in the Java stack). It's just that unlike in C, in Java, programmers don't have to worry about space release, and Java's garbage collection mechanism handles it automatically. So this part of the space is also the main area managed by the Java garbage collector. In addition, the heap is shared by all threads, and there is only one heap in JVM.

5. Method area

The method zone is also a very important area in JVM, which, like the heap, is shared by threads. In the method area, the information of each class (including class name, method information, field information), static variables, constants, and compiled code of the compiler are stored.

In addition to the description of the fields, methods, interfaces, and other information of the class in the Class file, another piece of information is the constant pool, which is used to store the literals and symbol references generated during compilation.

A very important part of the method area is the runtime pool, which is the runtime representation of the constant pool for each class or interface. After the classes and interfaces are loaded into the JVM, the corresponding runtime pool is created. Of course, it is not the contents of the constant pool of Class files that can be entered into the runtime constant pool, and new constants can also be put into the runtime constant pool during operation, such as String's intern method.

In the JVM specification, there is no mandatory requirement that the method zone implement garbage collection. Many people are used to calling the method zone "permanent generation" because the HotSpot virtual machine implements the method area with a permanent generation, so that JVM's garbage collector can manage this area as if it were a heap area, so there is no need to design a garbage collection mechanism specifically for this part. Since JDK7, however, the Hotspot virtual machine has removed the runtime pool from the permanent generation.

The above are personal views and views. If there are any irregularities, I hope you will understand and welcome to correct them.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Network Security

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report