Runtime data area
1. Program counter
A program counter is a small memory space that can be viewed as a line number indicator of the bytecode being executed by the current thread. In the concept of virtual machine model (it is only a concept model, all kinds of virtual machine may through some effective means to achieve), bytecode interpreter to work is by changing the value of the counter to select the next need to execute bytecode instruction, branches, loops, jumps, exception handling, thread to restore the basic function such as all need to rely on the counter.
Because multithreading in the Java virtual machine is implemented by switching threads in turn and allocating processor execution time, each processor will execute instructions from only one thread at any given time. Therefore, in order to recover to the correct execution position after thread switching, each thread needs to have an independent program counter, which is not affected by each other and 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 Native method is being executed, this counter value is null (Undefined). This memory area is the only one where the Task OutOfMenoryError condition is not specified in the Java Virtual Machine specification.
2. Java Virtual machine stack
Like program counters, the Java virtual machine stack is thread-private and has the same lifetime as a thread. The virtual machine stack describes the in-memory model of Java method execution; As each method executes, a stack of frames is created to store information about local variables, operand stacks, dynamic links, method exits, and so on. The process of each method from invocation to completion corresponds to the process of a stack frame being pushed into and out of the virtual machine.
The division of Java memory regions is actually much more complex than the crude division of Java memory into heap and stack memory. The popularity of this partition only shows that most programmers care most about these two areas of memory that are most closely related to the allocation of object memory. The heap referred to is now referred to as the virtual machine stack, or the local variable table in the virtual machine.
Local variables to store the compile time shows the various basic data types (Boolean, byte, char, short, int, float, long, double), object reference (reference types, it is not the same as the object itself, may be a pointer to the starting address of reference objects, It can also refer to a handle or other location associated with the object) and the returnAddress type (which refers to a bytecode address), where 64-bit longs and doubles take up two local variables and only one for the rest of the data type. The memory space required for the local variable table is allocated at compile time, and when entering a method that needs to allocate multiple local variable Spaces in the frame is fully determined, without changing the size of the local variable table while the method is running.
In the Java Virtual Machine specification, two exceptions are specified for this area: a StackOverflowError is thrown if the stack depth desired by the thread is greater than the depth allowed by the virtual machine; If the virtual stack can be dynamically extended (and most Current Java virtual machines can be dynamically extended, although the Java Virtual Machine specification also allows fixed-length virtual stacks), OutOfMenoryError will be raised if sufficient memory cannot be allocated during the extension.
3. Local method stack
The role of the Native method stack is very similar to that of the virtual machine stack. The difference between them is that the virtual machine stack executes Java method services for the virtual machine, while the Native method stack uses Native method services for the virtual machine. The virtual machine specification does not mandate the language, usage, or data structure of methods in the local method stack, so specific virtual machines are free to implement it. Some virtual machines simply combine the local method stack with the virtual machine stack. Like the virtual stack, the local method area throws StackOverflowError and OutOfMemoryError exceptions
4, the Java heap
The Java heap is the largest chunk of memory managed by the Java Virtual machine. The Java heap is an area of memory that is shared by all threads and is created when the virtual machine is started. The sole purpose of this memory area is to hold object instances, and almost all object instances are allocated memory here. This is described in the Java virtual machine specification is: all the object instance and array on the heap allocation, but with the development of the JIT compiler and escape analysis technology mature gradually, on the stack, the title to replace optimization technology will lead to some subtle changes, all objects are allocated on the heap gradually becomes not so absolute.
The Java heap is the primary area managed by the garbage collector and is often referred to as the “GC heap”. From the point of view of memory collection, the Java heap can be subdivided into: new generation and old generation;
More detailed are Eden space, From Survivor space, To Survivor space, etc. From a memory allocation perspective, a Java heap shared by threads can be partitioned into multiple thread-private allocation buffers (TLabs). However, no matter how to divide, it has nothing to do with the storage content, no matter which area, the storage is thrown like an object instance, the purpose of further division is to better reclaim memory, or faster allocation of memory.
According to the Java Virtual Machine specification, the Java heap can be in a physically discontinuous memory space, as long as it is logically contiguous, like our disk space. It can be either fixed size or extensible, but most current virtual machines are implemented as extensible. An OutOfMemoryError will be thrown if there is no memory in the heap for instance allocation and the heap can no longer be extended
5. Method area
The method area, like the Java heap, is an area of memory shared by individual threads to store data such as class information that has been loaded by the virtual machine, constants, static variables, code compiled by the just-in-time compiler, and so on. Although the Java Virtual Machine specification describes the method area as a logical part of the Heap, it has an alias called non-heap, which is supposed to distinguish it from the Java Heap.
Many people refer to the method area as “persistent generation”, which is essentially not equivalent, simply because the design team of the HotSpot VIRTUAL machine chose to extend the GCc generational collection to the method area, or to implement the method area using persistent generation, so that HotSpot garbage collector can manage this part of memory as well as the Java heap. The ability to eliminate the need to write memory-management code specifically for the method area makes the concept of perpetual generation nonexistent for other virtual machines.
In principle, how method areas are implemented is a virtual machine implementation detail and not subject to the virtual machine specification, but using persistent generation to implement method areas is not a good idea now because it is more likely to run into memory overflow problems. In JDK1.7, the string constant pool that was placed in the permanent generation has been removed. According to the Java Virtual Machine specification, OutOfMemoryError is thrown when the method area cannot meet memory allocation requirements.
Run time constant pool
Runtime constant pool is part of the method, in addition to the Classic file version of a class, field, method, interface description information, such as there is a information is constant pool, to hold compile-time generated a variety of literal and symbolic references, this part will be in after class loading into the method of runtime constants in the pool.
The Java Virtual Machine has strict rules on the format of each part of a Class file. Each byte must be used to store what kind of data is accepted, loaded, and executed by the virtual machine. However, the Java Virtual Machine specification does not specify any details about the runtime constant pool. Virtual machines implemented by different vendors can implement this memory area according to their needs. However, in general, in addition to storing symbolic references described in Class files, translated direct references are also stored in the runtime constant pool.
Runtime constant pool relative to the Class file another important feature of the constant pool is dynamic, the Java language does not require constant must only compile time to produce, is not preset constant pool into the Class file content can enter method area runtime constant pool, runtime might also put new constants in a pool, One feature that developers use most often is the Intern () method of the String class.
Since the runtime constant pool is part of the method area and is naturally limited by the method area memory, OutOfMemoryError is thrown when the constant pool can no longer claim memory.
7. Direct memory
Direct memory is not part of the runtime data area of the virtual machine, nor is it defined in the Java Virtual Machine specification. However, this portion of memory is also frequently used and can cause OutOfMenoryError exceptions.
The NIO class was added in JDK1.4, introducing a channel-buffer-based IO approach that uses Native libraries to allocate out-of-heap memory directly and then operate as a reference to that memory via a DirectByteBuffer object stored in the Java heap. This can significantly improve performance in some scenarios because it avoids copying data back and forth between the Java heap and Native heap.