It’s really hard for developers to write good code and find good bugs if they don’t understand the Java JVM. The JVM is also a disaster during the interview process. Today, the JVM In Detail series kicks off with an in-depth look at the JVM.
We can’t just interview for interview’s sake, but learning these core things will make you one of the brightest stars in the interview and job. This series was first published on the wechat public account “Program New Vision”. Let’s start with our first article, “Inside the JVM Structure.”
Learning is also to pay attention to the method, this series of learning process will guide you through the “Feynman learning method” to learn, at the same time, try to use the way of pictures and texts to explain. A picture is worth a thousand words.
Think about it
When you learn something, you must know why you are learning it. Some people might say, well, it doesn’t seem like it’s useful to write code. It seems like the JVM does everything for us. Consider why you want to learn about JVM virtual machine architecture.
Do you get confused about how much heap memory to set? How is OutOfMemoryError caused? How do I tune the JVM? What is JVM garbage collection like? Even creating a String, what does the JVM do?
These questions will be answered as we go along, and the first step to solving these questions is to understand what the JVM is made of.
JVM memory structure
The Java virtual machine divides memory into different data areas during program execution, as shown in the following figure.
If you understand the figure above, the JVM’s memory structure is pretty much half understood. What can we see from the picture above? Amateurs watch the crowd, amateurs watch the door. The following information can be obtained from the figure.
First, the JVM is divided into five regions: the virtual machine stack, the local method stack, the method area, the heap, and the program counter. PS: Don’t exclude English. It’s easier to remember in English.
Second, the virtual machine stack, local method stack, and program counters are thread private, and the method area and heap are thread shared. The figures are color-coded, with green indicating “go” and orange indicating stop (wait).
Third, different areas of the JVM have different memory footprint, with the heap generally being the largest and the program counter small. So what would be the largest area? Is, of course, the most “object” in Java.
Learning extension: If you remember this diagram, can you say something about the MEMORY structure of the JVM? Try it. Don’t memorize it. Use your imagination.
Heap (Heap)
It has already been concluded that the heap has the largest memory, the heap is shared by threads, and the purpose of the heap is to hold objects. Almost all object instances are allocated here. Of course, as optimization techniques are updated, some data will also be placed on the stack.
A single shot catches the first bird. The Heap is also known as the “Garbage Collected Heap” because it occupies the largest amount of memory and is the primary area (focus object) for Java Garbage collection.
The operation of the GC will be covered in more detail in a later section, but the heap has been refined because of the EXISTENCE of the GC, and modern collectors generally use generational collection algorithms.
Similarly, summarize and analyze the content presented in the figure above.
First, the GC operation of heap adopts generational collection algorithm.
Second, the heap distinguishes the Cenozoic from the old;
Third, the new generation is divided into Eden space, From Survivor (S0) space and To Survivor (S1) space.
The Java Virtual Machine specification states that the Java heap can be in a physically discontinuous memory space, as long as it is logically contiguous. That is, the memory of the heap is pieced together. To increase the heap space, “scrape” up (scalability) is enough, but OutOfMemoryError is thrown when there is no memory in the heap to complete the instance allocation and the heap can no longer be expanded.
Method Area
Method areas have a lot in common with the heap: thread sharing, memory discontinuity, extensibility, garbage collection, and also throw OutofMemoryErrors when they can no longer be extended.
Because of this similarity, the Java virtual Machine specification describes the method area as a logical part of the Heap, but is currently actually non-heap from the Java Heap.
The method area is personalized because it stores information about classes that have been loaded by the virtual machine, constants, static variables, code compiled by the just-in-time compiler, and so on.
The target of the method area’s memory reclamation is mainly for the constant pool reclamation and the unloading of the type. Generally speaking, the “performance” of the reclamation in this area is not satisfactory, especially for the unloading of the type, the condition is quite harsh, but the reclamation is indeed necessary.
Program Counter Register
We already know about program counters: small footprint, ready to private. It is the only region without an OutOfMemoryError exception.
A program counter can be seen as a line number indicator of the bytecode being executed by the current thread. The bytecode interpreter works by changing the value of the counter to select the next bytecode instruction. Among them, branch, loop, jump, exception handling, thread recovery and other basic functions need to rely on counters to complete.
Multithreading in the Java VIRTUAL machine is implemented by the way that threads alternate and allocate processor execution time, so that at any given moment, one processor (or kernel for multi-core processors) will execute instructions in only one thread.
Therefore, in order to restore the thread to the correct execution position after switching, each thread needs to have an independent program counter. Counters between threads do not affect each other and are stored independently. We call this kind of memory area “thread private” memory.
If the thread is executing a Java method, this counter records the address of the virtual machine bytecode instruction being executed. If the Natvie method is being executed, this counter value is null (Undefined).
JVM Stacks
Virtual stack threads are private and have the same life cycle as threads.
A Stack Frame is a data structure used to support method invocation and method execution by a virtual machine. A stack frame stores information about a method’s local variogram, operand stack, dynamic linkage, and method return address. The process of each method from invocation to completion corresponds to the process of a stack frame in the virtual machine stack from loading to unloading.
Local Variable Table is a set of Variable value storage space used to store method parameters and Local variables defined in methods. There are eight basic data types, object reference types, and returnAddress types, which refer to the address of a bytecode instruction.
64-bit long and double data occupy two local variable slots, and the rest occupy only one.
StackOverflowError is raised if the thread requests a stack depth greater than the virtual machine allows. OutOfMemoryError is raised if sufficient memory cannot be allocated during dynamic stack expansion.
An Operand Stack, also known as an operation Stack, is a LIFO Stack. As the method is executed and the bytecode instruction is executed, constants or variables are copied from the fields of the local variable table or object instance and written to the operand stack, and the stack elements are either pushed off the stack to the local variable table or returned to the method caller as the calculation proceeds, i.e., pushed/pushed.
Dynamic Linking: In the Java virtual machine stack, each stack frame contains a symbolic reference to the method that the stack belongs to in the runtime constant pool. This reference is held to support Dynamic Linking during method invocation.
Method return: Whether or not a method completes normally, it needs to return to the point where the method was called before the program can continue.
Native Method Stacks
Native Method Stacks can also throw StackOverflowError and OutOfMemoryError.
The difference is that the virtual machine stack performs Java method (bytecode) services for the virtual machine, while the Native method stack serves Native methods used by the virtual machine.
summary
After all this, you should already know the basics of the JVM’s memory structure. So let’s sum it up against the brain map and see how much you can say.
For more details on JVM and other interview questions, please pay attention to the wechat public account “Program New Vision” and continue to update.
JVM Memory Structure In Detail
Program new horizon
