directory
• Write it first
• Program counter
• Java virtual machine stack and native method stack
• Java heap
• method area
• Write it first
The Java Virtual machine run-time data area is the way we need to get to the bottom of the JVM. What kind of area is this? Java virtual machine in the process of executing the Java program, will divide the memory it management a number of different data areas, these areas are endowed with different purposes, they each have created and destroyed, some area is with the virtual machine process started, some area is dependent on user thread start and end and set up and destroyed. It is a kind of model specification that Java virtual machines are built to follow. We could draw it roughly as a graph, which would look something like this.
Thread isolation and thread sharing will be discussed in more detail in separate sections of data, but you only need to have a rough idea of whether they belong to a single thread or to an entire region.
• Program counter
First of all, let’s talk about the program counter, the program counter, it is in a different virtual machine has a different implementation, after all relative to the application of independent counting algorithm, often have many more optimized and efficient algorithms can be used, so here we are mentioned the concept of the program counter is in the memory model of the virtual machine, The implementation varies from vm to VM. In the conceptual model, the program counter is a small memory space, which can be regarded as a line number indicator of the bytecode being executed by the current thread. The bytecode interpreter works by changing the value of this counter to select the next bytecode instruction to be executed. Basic functions such as branching, looping, jumping, exception handling, thread recovery, and so on rely on this counter.
To make things easier to understand, I’ll open a compiled bytecode file and post it, and you’ll see that in hexadecimal, it’s an addressing process. (You can also find a class file and use the winhex widget instead of notepad.)
Since multithreaded Java virtual machine is through the thread switching in turn and allocate processor execution time, at any moment, for sure, a processor can only execute a thread in the instruction, therefore, in order to thread after switching to restore to the execution of the right position, each thread requires a separate program counter, Counters are stored independently of each other, so program counters are “thread private” memory areas.
It is important to note that the thread is executing a Java method. The program counter records the address of the virtual machine bytecode instruction being executed, which IS the memory offset ADDRESS I marked above. If a native method is executed, the program counter is empty, i.e., undefined. And the program counter piece of memory is the only area where the Java Virtual Machine specification does not specify any OutOfMemoryError cases.
• Java virtual machine stack and native method stack
Like the program counter, the Java virtual stack is thread-private and has the same lifetime as the thread. The virtual stack describes the in-memory model of the execution of Java methods, which goes something like this: When each method is executed, a stack frame will be created to store information such as local variable table, operand stack, dynamic link, method exit, etc. The process of each method from being used to the completion of execution is the corresponding process of a stack frame in the virtual machine stack.
The local variable table contains basic data types known at compile time (Boolean, int, float, etc.), object references (the reference type), which is a reference pointer to the starting address of the object. It can also point to a handle representing an object or other location associated with the object, or returnAddress (which points to the address of a bytecode instruction).
The basic data types long and double are 64 bits long, so they take up two Spaces in the local variable table and only one for the rest of the data. The memory space required for local variables is allocated at compile time. When entering a method, how much local variable space the method needs to allocate in the frame is determined. The method does not change the size of the local variable table during execution.
For the Java virtual machine Stack, two exceptions are specified. The first is that a Stack OverflowError is raised if the Stack depth requested by the thread is greater than the depth allowed by the virtual machine. The second is that OutOfMemoryError is thrown if the virtual stack can be extended dynamically, but the extension cannot allocate enough memory.
Local method stack, the reason and the virtual machine stack together, because the two functions are very similar, the difference between them is a virtual machine stack work for execution of a Java virtual machine method, and the regional development is a Native method of execution work (Java and Native things pretty much, interested in another article, look at me I’m going to focus on these two things.)
• Java heap
The Java heap should be the largest chunk of memory we’re dealing with, and unlike the areas mentioned above so far, the Java heap is a chunk of memory shared by all threads. Created when the VM starts. The only purpose of this memory is to hold object instances. Almost all object instances are allocated here. When we look at the Java Virtual Machine specification, it describes this: All object instances and arrays are allocated on the heap, but with the development of JIT compilers and escape analysis techniques, allocation on the stack and scalar replacement optimization techniques will lead to subtle changes, and all objects allocated on the heap will become less absolute.
Because all the instances we create are allocated on the heap, the virtual machine’s garbage collection is mainly for the Java heap, so the Java heap is also referred to as the GC heap. From the point of view of memory recovery, because now the collector basic collection algorithms use zoning, so the Java heap can be further subdivided into new generation and the old S, is a further E area and two S area, about a generational GC algorithm involved, you can refer to my another article, specifically for GC algorithm in detail. From a memory allocation point of view, it is possible to have multiple thread-private allocation buffers in a thread-shared Java heap, but no matter how they are divided, they are all object instances. Right
• method area
Like the Java heap, the method area is an area of memory shared by threads to store 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. If you look into the Java virtual machine specification, the method area is described as a logical part of the Heap, but it is also called non-heap to distinguish it from the Java Heap. In particular, the method area, like the Java heap, does not require continuous memory and can be either fixed size or extensible, and can also be garbage collected. In a definite way recycling behavior in this area is less, but not data into the area was a permanent (method has been used to make permanent generation), the area of memory recovery goal mainly is aims at the constant pool of recycling and the type of discharge, generally the area of recycling is difficult to reach the expected effect, After all, the storage is some “old things”, especially the type of unloading, the conditions are quite harsh, but anyway, or need to carry out garbage collection.
There is a special section in the method area called the runtime constant pool. The compiled Class file contains the version, field, method, and interface of the Class, as well as the constant pool, which is used to store the literal and symbolic references generated by the compiler when the Class is loaded into the method area.
We know, the Java virtual machine for each part of the Class file format has strict rules, each byte is used to store which data must be accord with the requirement of specification on the virtual machine can be recognized, loading and execution (the above that the content of the Class files, you don’t feel like it, it has a strict format). However, the Java Virtual Machine specification does not specify any details about runtime constant pools, and VMS from different vendors have different implementations. However, in general, in addition to storing symbolic references described in Class files, translated direct references are also stored in the runtime constant pool. The Java language does not require a constant to be generated only by the compiler. That is, it is possible to put new constants into the method area runtime constant pool during runtime. The most common use of this feature is the String intern() method.