Deep understanding of Java Virtual Machine (i)

JIT compiler , English writing just-in-time Compiler, Chinese means instant compiler

The reason the class field does not need to be initialized:

After the memory allocation is complete, the virtual machine needs to initialize the allocated memory space to a value of 0 (excluding the object header), and if Tlab is used, the work process can also be advanced to Tlab allocation. This step ensures that an instance field of an object can be used directly in Java code without assigning an initial value, and the program can access the 0 value corresponding to the data type of those fields.

The process of generating a Java object from a virtual machine:

1) First, check that the parameter of this directive is able to locate the symbolic reference of a class in the constant pool, and check that the class that the symbol reference represents has been loaded, parsed, and initialized. If not, you must first perform the appropriate class loading process

2) After the class load check passes, the virtual machine will then allocate memory for the new object (pointer collisions, idle lists) (whether the Java heap is structured)

(One is to synchronize the action of allocating memory space--in fact, the virtual machine uses the CAS with the failure retry to ensure the atomicity of the update operation, the other is the memory allocation of the action according to the thread divided into different space, that is, each thread in the Java heap pre-allocated a small block of memory, Called Local thread allocation buffer (thread local Allocation buffer,tlab))

3) After the memory allocation is complete, the virtual machine needs to initialize the allocated memory space to 0 values (excluding object headers)

4) Next, the dummy will make the necessary settings for the object, such as which instance of the class it is, how to find the metadata information of the class, the hash code of the object, the age of the GC for the object, and so on. This information resides in the object header of the object.

5) After the work is done, a new object has been created from the virtual machine perspective, but from the Java program perspective, object creation has just begun-the method has not been executed and all fields are zero. So, in general (as determined by the Invokespecial directive in bytecode), the method is followed by the execution of the new instruction, which initializes the object according to the programmer's will, so that a truly usable object is fully generated.

Memory layout of objects in virtual machines:

Object header, instance data, aligned padding

The object header of a hotspot virtual machine includes two pieces of information, the first part is used to store the object's own runtime data, such as hash code (HASHCODE), GC generational age, lock status flag, thread holding lock, biased thread ID, biased timestamp, etc., and the other part of the object header is the type pointer. That is, the object points to its class metadata pointer, which the virtual machine uses to determine which class the object is an instance of. (Not all virtual machine implementations have to keep type pointers on object data, in other words, finding the object's metadata information does not necessarily go through the object itself).

The instance data section is a valid piece of information that the object actually stores, as well as the various types of field content defined in the program code (the default allocation policy for the hotspot virtual machine is longs/doubles, INTs, Shorts/chars, Bytes/booleans, Oops (ordinary Object pointers), as can be seen from the allocation policy, fields of the same width are always assigned together. ）

The third part of the alignment padding does not necessarily exist, there is no special meaning, it only plays the role of placeholder (because the hotspot VM's automatic memory management system requires that the object start address must be an integer multiple of 8 bytes, in other words, the size of the object must be an integer multiple of 8 bytes.) The header portion of the object is exactly a multiple of 8 bytes (1 time times or twice times), so when the object instance data part is not aligned, it needs to be filled by aligning the padding. ）

Object Access Location:

Java programs need to manipulate the concrete objects on the heap through the reference data on the stack.

There are two ways to access the current mainstream: using a handle and a direct pointer.

With a handle, a chunk of memory will be partitioned into the Java heap as a handle pool, where the handle address of the object is stored, and the handle contains the specific address information of the object instance data and the type data reference.

With direct pointer access, the layout of the Java heap object must consider how to place information about the access type data, and the object address is stored directly in the reference

The biggest benefit of using a handle to access is that a stable handle address is stored in reference, and only the instance data pointers in the handle are changed when the object is moved (garbage collection is a very common behavior), and reference itself does not need to be modified The biggest benefit of using direct pointer access is faster speed, which saves time spent on pointer positioning, because object access is very frequent in Java, so this overhead is a significant execution cost.

Java Heap Overflow:

The Java heap is used to store object instances, as long as the objects are constantly created, and the GC roots to the object to avoid the garbage collection mechanism from clearing these objects, a memory overflow exception occurs when the number of objects reaches the maximum heap capacity limit.

The point is to make sure that the objects in memory are necessary to get a sense of whether a memory leak or a memory overflow occurred.

Memory overflow: Code restricts the Java heap size to 20MB, is not extensible (the heap's minimum-xms parameter is set to the same as the maximum-xmx parameter to avoid heap auto-expansion), through parameters-xx:+ Heapdumponoutofmemoryerror allows the virtual machine to dump the current memory heap in the event of a memory overflow exception

Dump snapshots for post-mortem analysis [1]

Memory leaks: Leaking objects are associated with GC roots through paths and cause the garbage collector not to automatically reclaim their (commonly said GC (garbage Collector) roots, specifically the garbage collector (garbage Collector) object, The GC collects objects that are not GC roots and are not referenced by GC roots. ）

If there is no leakage, in other words, the objects in memory must still exist, then you should check the virtual machine's heap parameters (-xmx and-XMS), compared with the machine physical memory to see if it can be larger, from the code to check if there are some object life cycle is too long, hold the state of the time is too long, Try to reduce the memory consumption during program run time.

Virtual machine stack and local method stack overflow:

A Stackoverflowerror exception is thrown if the thread requests a stack depth that is greater than the maximum allowed depth for the virtual machine. Throws a OutOfMemoryError exception if the virtual machine cannot request enough memory space on the scale stack. ( Here the exception is divided into two cases, seemingly more rigorous, but there are some overlapping places: when the stack space can not continue to allocate, whether the memory is too small, or the stack space used is too large, it is essentially only two descriptions of the same thing)

The more classes (or dynamic classes) are enhanced, the larger the method area is required to ensure that the dynamically generated class can be loaded into memory. Dynamic languages on the JVM (such as groovy and so on, Java reflection) often create classes to achieve the dynamic nature of language, and as such languages become popular, they are increasingly prone to memory overflow in the method area.

Native Direct Memory Overflow:

Directmemory capacity can be specified by-xx:maxdirectmemorysize and, if not specified, the default is the same as the Java heap maximum (-xmx specified)

Although allocating memory using Directbytebuffer also throws a memory overflow exception, it throws an exception and does not actually request the operating system to allocate memory, but calculates that the memory cannot be allocated, and then throws the exception manually. The real way to apply for allocating memory is unsafe.allocatememory ().

All objects associated with GC roots cannot be recycled by GC;

There are several objects that can be used as GC Roots:

The object referenced in the virtual machine stack (the local variable table in the stack frame);

The object referenced by the class static property in the method area;

The object referenced by the constant in the method area;

The object referenced by JNI (that is, generally speaking, the native method) in the local method stack;

Reference types for Java:

The references are divided into strong references (strongreference), soft references (softreference), weak references (Weak Reference), virtual references (phantomreference) 4, and these 4 reference intensities gradually weaken in turn.

Compile-time three types of compilers:

Front-end compiler: Javac in Sun, incremental compiler in Eclipse JDT (ECJ) [1]. (The process of converting a *.java file into a *.class file)

JIT compiler: C1, C2 compiler for HotSpot VMs. (The process of converting bytecode into machine code)

AOT compiler: GNU Compiler for the Java (GCJ) [2], Excelsior jet[3]. (The process of compiling the *.java file directly to the cost of the machine code)

From the Sun Javac Code, the compilation process can be broadly divided into 3 processes, namely:

Parse and populate symbol table procedures.

annotation processing for the plug-in annotation processor.

Parsing and bytecode generation process.

Deep understanding of Java Virtual Machine (i)