"Go" JVM memory model

Article source (citation): http://topic.csdn.net/u/20090602/10/bd9d4ba2-dbeb-49b3-8651-67c5de2b228a.html

, the JVM mainly consists of two subsystems and two components. The two subsystems are the class loader subsystem and the execution engine (execution engine) subsystem, and the two components are the runtime data area (run time) components and the native interface (local interface) components respectively.

The role of the Class loader subsystem:

Loads the contents of a class file into the method area in the Runtime data zone, based on the given fully qualified name Class name (such as Java.lang.Object). Java programmers can extends Java.lang.ClassLoader classes to write their own class loader.

The role of the execution engine subsystem:

Executes the instructions in the classes. The core of any JVM specification implementation (JDK) is the execution engine, and the different JDK such as Sun's JDK and IBM's JDK are largely dependent on the quality of their respective execution engine implementations.

Native Interface Components:

Interacting with native libraries is an interface for other programming language interactions. When the native method is called, it enters a completely new world that is no longer restricted by the virtual machine, so it is also easy to have native heap OutOfMemory that the JVM cannot control.

Runtime Data Area components:

This is what we often call the JVM's memory. It is mainly divided into five parts--
1. Heap: Only one heap space exists in a Java virtual instance
2. Method Area: The information of the loaded class is stored in the memory of method zone. When a virtual machine loads a type, it uses the class loader to locate the appropriate class file and then reads the class file contents and transfers it to the virtual machine.
3. Java stack (Java stacks): Virtual machines only perform two operations on the Java stack directly: stack or stack in frames
4, program Counter (Programs counter): Each thread has its own PC register, which is also created when the thread starts. The contents of the PC register always point to the next hungry address where the instruction will be executed, where the address can be either a local pointer or an offset relative to the method's start instruction in the method area.
5, Native method Stack (local methods stack): Save Native method to enter the address of the zone

Only the heap and method area are shared by all threads, while Java stack, program counter, and native method stack are thread-grained, each with its own part.

The principle of Sun's JVM generational collecting (garbage collection) is that it divides objects into younger generations (young), older generations (tenured), persistent generations (Perm), and uses different algorithms for objects of different lifecycles. (Based on the object life cycle analysis)

As shown, it is distributed across generations in the Java heap.
1. Young (younger generation)
The young generation is divided into three districts. One Eden area, two survivor districts. Most objects are generated in the Eden area. When the Eden Zone is full, the surviving objects will be copied to the Survivor area (one of two), and when the survivor area is full, the surviving objects of this area will be copied to another survivor area, when the survivor is full, Objects that are copied from the first survivor area and that are still alive will be duplicated in the old age zone (tenured. It should be noted that the two areas of the survivor are symmetrical and have no relationship, so the same area may exist at the same time from Eden copied objects, and from the previous survivor copied objects, and copied to the old quarter only from the first survivor to come over the object. Moreover, there is always an empty survivor area.
2. Tenured (old generation)
Older generations store objects that survive from younger generations. In general, older generations are storing long-term objects.
3. Perm (Permanent Generation)
Used to store static files, now Java classes, methods, and so on. The persistence generation has no significant impact on garbage collection, but some applications may dynamically generate or invoke some classes, such as Hibernate, at which point a large, persistent generation space is required to store the new class in these runs. The persistent generation size is set by-xx:maxpermsize=.

For example, when an object is generated in a program, the normal object allocates space in the younger generation, and if the object is too large, it may be generated directly in the old generation (it is observed that each time a program is run, a 10 trillion space is generated for sending and receiving messages, and this memory is allocated directly to the old generation). The young generation will initiate a memory recovery when the space is allocated, most of the memory will be recycled, a portion of the surviving memory will be copied to the survivor from zone, and after multiple collections, if the From zone memory is also allocated, then a memory recycle will occur and the remaining objects will be copied to the to area. When the to area is full, a memory recycle occurs and the surviving objects are copied to the old quarter.

Usually we say that the JVM memory recycle is always referred to as heap memory recycling, indeed only the content in the heap is dynamically requested to allocate, so the young and old generations of the above objects refer to the JVM's heap space, and the persistent generation is the previously mentioned method area, which is not part of the heap.

a parameter meaning:

Reference: http://longdick.iteye.com/blog/468368

When the JVM starts, it retains a fixed amount of memory to the heap memory, which is not necessarily used by the JVM, but it can be determined that this portion of the reserved memory is not used by other processes. This part of the memory size is determined by -Xmx 参数指定。

In the other part, the JVM is allocated to the JVM when it is started, and is used as the JVM's initial heap memory. The parameter that affects this is-XMS, if the value specified by-XMS is smaller than-xmx, then the difference between the two is virtual memory value. As the program runs, the Eden, tenured, and perm areas will gradually use the reserved virtual space.

If unspecified, the initial and maximum heap memory is calculated based on the machine's memory. Parameters DefaultInitialRAMFraction and DefaultMaxRAMFraction will affect the final result, as shown in the following table:

Formula Default

Initial Heap Size	memory / DefaultInitialRAMFraction	memory /64
Maximum Heap Size	MIN(memory / DefaultMaxRAMFraction, 1GB)	MIN(memory/ 4, 1GB)

You can see that the default value of heap memory is no more than 1G.

The JVM automatically determines when to expand and reduce the actual heap memory size based on the usage of the heap memory, which can be used with VM parameters -XX:MinHeapFreeRatio=<minimum> and-XX:MaxHeapFreeRatio=<maximum> 使用堆内存空闲百分比来定义，一般在32位机器上的默认值如下：


Parameter Default Value

MinHeapFreeRatio	40
MaxHeapFreeRatio	70
-Xms	3670k
-Xmx	64m

When the free heap memory percentage of heap memory is less than 40%,JVM, it attempts to expand the heap memory space and attempts to compress the heap memory space when the percentage of heap memory occupied by the free heap memory is higher than 70%,JVM.

PS: The above default values will have different values on different platforms, and if it is a 64-bit system, these values typically need to be expanded by 30% to accommodate objects that become larger under the 64-bit system.

Plus -XX:NewRatio=3 that means young (younger generation) and tenured (lifetime generations) are 1:3, meaning that the sum of the Eden and survivor areas will account for 1/4 of the total heap of memory.

加上-XX:SurvivorRatio=6The ratio of setting Eden area to one of survivor space is 1:6, that is, one survivor space represents the capacity of the younger generation 1/8 (you can think about why not 1/7).

In addition, there are -XX:NewSize -XX:MaxNewSize  指定年轻代的初始值和最大值。

The default values for 32-bit systems are as follows:

Default Value Parameter Client JVM Server JVM

NewRatio	8	2
NewSize	2228K	2228K
MaxNewSize	not limited	not limited
SurvivorRatio	32	32

"Go" JVM memory model