Introduction to the memory of Java virtual machines

This article mainly introduces the memory distribution of Java Virtual machine and the process of object creation.

One, the memory distribution of the Java Virtual machine

Before the article begins, readers need to understand how the Java Virtual machine's run-time data area is partitioned. As shown in the following:

1. Program Counter (Programs Counter Register)

A program counter is a small amount of memory space that can be thought of as the line number indicator of the byte code executed by the current thread.

Because the multithreading of a Java Virtual machine is implemented in a way that threads rotate and allocate processor execution time, at any given moment, a processor (a kernel for a multicore processor) executes only the instructions in one thread. Therefore, in order for the thread to switch back to the correct execution location, each thread needs to have a separate program counter.

The counters between the threads do not affect each other and are stored separately, and we call this memory area " thread-Private ".

Readers familiar with C + + should understand the concept of "field protection", although "field protection" corresponds to a function call, and here the program counter corresponds to the switch between threads, but I think they are very similar: all for the thread or function can be restored to the correct position after execution.

2. Java VM Stack (Java Virtual machine Stacks)

What we call the stack area is the Java Virtual machine stack.

Like program counters, the Java Virtual machine stack is thread-private, with the same life cycle as the thread.

The virtual machine stack describes the memory model that the Java method executes: Each method creates a stack Frame to store information about the method, such as the local variable table, the operand stack, the exit of the method, and so on.

Each method from the call until the completion of the process, corresponding to a stack frame into the stack to the process of the stack.

The local variable table holds various basic data types (Boolean, Byte, char, short, int, float, long, double), object references (reference types) that are known at compile time. Not the object itself) and the ReturnAddress type (pointing to the location of a bytecode directive).

In the Java Virtual Machine specification, two exception conditions are specified for this area: Stackoverflowerror and OutOfMemoryError exceptions.

3, Java heap

The Java heap is the largest piece of memory managed by a Java virtual machine that is shared by all threads and created when the virtual machine is started. The only purpose of this memory area is to hold object instances where almost all of the object instances are allocated memory. Since almost all instances are stored in the Java heap, this naturally becomes a major area of garbage collector management.

An OutOfMemoryError exception is thrown when there is no memory in the pair that completes the instance assignment and the heap can no longer be expanded.

4. Method Area

The method area, like the Java heap, is an area of memory shared by each thread.

It is used to store data such as the class information that has been loaded by the virtual machine, constants, static variables, instant compiler compiled code, and so on.

The method area also includes a run-time-constant pool.

The OutOfMemoryError exception is thrown when the method area does not meet the memory allocation requirements.

5, the local method stack (Native methods stack)

The local method stack is very similar to the virtual machine stack, but the difference is that the virtual machine stack executes Java methods (that is, bytecode) services for the virtual machine, while the local method stack serves the native method used by the virtual machine.

In the virtual machine specification the language used by the local method stack method, the mage used and the data structure are not mandatory, so the specific virtual machine is free to implement it. Even some virtual machines, such as Sun HotSpot virtual machines, combine the local method stack and the virtual machine stack directly.

The data area throws the same exception as the virtual machine stack: Both Stackoverflowerror and OutOfMemoryError exceptions are thrown.

6. Running constant pool (runtime Constant)

The run-time-constant pool is part of the method area. Although the Java virtual machine does not separate the memory space for the run-time pool, it also has a separate entry for it because the area is an important part of the development in peacetime.

In addition to the class file's description of the version, field, method, and interface, there is also a constant pool (Constant pool Table), which holds the various literal references generated during the compilation period, which are stored in the run-time pool where the class loads the backward into the method area.

Another important feature of running a constant pool relative to a class file's const pool is dynamic, and the Java language does not require constants to be generated only at compile time, which means that the contents of the constant pool in the class file are not pre-placed to enter the method area to run the frequent pool. It is also possible to put new constants into the pool during run time, such as The Intern () method of the String class.

Since the run-time pool is part of the method area, it is naturally constrained by the memory of the method area, which throws a OutOfMemoryError exception when the constant pool is no longer able to apply to memory.

second, the creation of the object process

Java is an object-oriented language, and objects are created all the way through the course of a Java program. At the language level, the production is simply a new keyword, and in a virtual machine it is not so simple:

　　Virtual opportunity to a new directive, first checks whether the parameters of this directive can be located in a constant pool of a class's symbolic reference, and is known whether the symbol refers to the class is loaded, parsed, and initialized.　　If not, you must first perform the appropriate class loading process. After the class load check passes, the virtual machine allocates memory for the new object in the Java heap (the amount of memory required by the object is fully determined after the load is completed). Next, the virtual agent makes some necessary settings for the object, such as the object is the instance of which class, the object's hash code, the object's GC generational age, and so on. This information resides in the object header of the object.

After the work is done, from the virtual machine perspective: A new object has been created, but from the Java program's point of view: object creation has just begun--<init> method has not been executed, all fields are still zero. In general, after executing the new instruction, the <init> method is followed and the object is initialized as the programmer wishes. Such a truly usable object is fully produced.

This article is the author of the first article, the article will inevitably have errors and deficiencies in the place, but also please correct me.

Introduction to the memory of Java virtual machines