Shulou(Shulou.com)06/02 Report--

Internet Fox Glory Chess the latest version of the source code: http://hubawl.com/thread-164-1-1.html

Contains a full set of PC source code + some mobile lua source code (including more than 10 sub-games)

Runtime data area: thread shared data area: method area, heap, local library interface thread isolated data area: virtual machine stack, local method stack, program counter

Program counter: a small piece of memory that can be seen as a line number indicator of the bytecode executed by the current thread. This memory region is the only one that does not specify any OutOfMemoryError conditions in the Java virtual machine specification.

Java virtual machine stack: its life cycle is the same as that of threads. Virtual machine stack describes the memory model of Java method execution: each method creates a stack frame to store local variable table, Operand stack, dynamic link, method exit and so on. From the call to the completion of the execution of each method, there is a stack frame in the virtual machine stack from the stack to the stack process. The local variable table stores various basic data types known at compile time, object references (reference type, which is not equivalent to the object itself) and returnAddress type (which points to the address of a bytecode instruction). Of these, 64-bit data of long and double types takes up two local variable spaces, while the rest of the data types occupy only one. The memory space required by the local variable table is allocated during compilation. When entering a method, how much local variable space needs to be allocated in the frame is completely determined, and the size of the local variable table will not be changed during the operation of the method. In the Java virtual machine specification, two exception conditions are specified for this area: if the stack depth requested by the thread is greater than the depth allowed by the virtual machine, a StackOverflowError exception will be thrown; if the virtual machine stack can be dynamically extended, if enough memory cannot be applied for, an OutOfMemoryError exception will be thrown.

Local method stack: the role of the local method stack is very similar to that of the virtual machine stack, except that the virtual machine stack performs java methods (that is, bytecode) services for the virtual machines, while the local method stacks serve the Native methods used by the virtual machines. In the virtual machine specification, there is no mandatory stipulation on the language, usage and data structure of the method in the local method stack, so the specific virtual machine can implement it freely. Some virtual machines (such as Sun HotSpot virtual machines) directly combine the local method stack and the virtual machine stack into one. Like the virtual machine stack, the local method stack throws StackOverflowError and OutOfMemoryError exceptions.

Java heap: for most applications, the Java heap is the largest block of memory managed by the Java virtual machine. The Java heap is an area of memory shared by all threads and is created when the virtual machine starts. The sole purpose of this memory area is to store object instances, where almost all object instances allocate memory. From the point of view of memory recovery, because the current collectors basically use generation-by-generation collection algorithm, the Java heap can also be subdivided into: new generation and old age; more detailed, there are Eden space, From Survivor space, To Survivor space and so on. From a memory allocation point of view, a Java heap shared by threads may be divided into allocation buffers (Thread Local Allocation Buffer,TLAB) that are private to multiple threads. However, no matter how divided, it has nothing to do with storing content, no matter which area, the storage is still an object instance. The purpose of further partitioning is to better reclaim memory, or to allocate memory faster. According to the Java virtual machine specification, the Java heap can be in physically discontiguous memory space, as long as it is logically continuous. When implemented, it can be either fixed size or extensible, but the current mainstream virtual machines are implemented according to extensibility (through-Xmx (maximum) and-Xms (minimum) control). If there is no memory in the heap to complete the instance allocation, and the heap can no longer be expanded, an OutOfMemoryError exception will be thrown.

Method area: like the Java heap, the method area is a memory area shared by each thread. It is used to store class information, constants, static variables, compiled code and other data that have been loaded by the virtual machine. Although the Java virtual machine specification describes the method area as a logical part of the heap, it has an alias called Non-Heap (non-heap), which is supposed to distinguish it from the Java heap. Method areas are not inherently equivalent to permanent generations, simply because the design team of the HotSpot virtual machine chose to extend GC generational collection to the method area, or use permanent generations to implement the method area, so that HotSpot's garbage collector can manage this part of memory like a Java heap, eliminating the need to write memory management code specifically for the method area. For other virtual machines (such as BEA JRockit, IBM J9, etc.), there is no concept of permanent generation. In principle, how to implement the method area belongs to the virtual machine implementation details and is not bound by the virtual machine specification, but it does not seem like a good idea to use permanent generation to implement the method area, because it is more likely to encounter memory overflow problems (permanent generation has an upper limit of-XX:MaxPermSize, J9 and JRockit will not have a problem as long as they do not touch the upper limit of the available memory of the process, such as 4GB in 32-bit systems). The string constant pool that was originally placed in the permanent generation has been removed from JDK1.7 's HotSpot. According to the Java virtual machine specification, an OutOfMemoryError exception is thrown when the method zone cannot meet the memory allocation requirements.

Run-time pool: the run-time pool is part of the method area. In addition to the version, field, method, interface and other description information of the class, another piece of information in the Class file is the constant pool, which is used to store all kinds of literals and symbolic references generated during compilation. This part of the content is stored in the runtime pool of the method area after the class is loaded. Because the runtime pool is part of the method area, it is naturally limited by the memory of the method area, and an OutOfMemoryError exception is thrown when the constant pool can no longer apply for memory.

Direct memory: direct memory is not part of the runtime data zone of the virtual machine, nor is it the memory area defined in the Java virtual machine specification. However, this part of memory is also frequently used, and may also lead to OutOfMemoryError exceptions. A new NIO (New Input/Output) class is added to JDK1.4, which introduces an IJDK1.4 O method based on channel (Channel) and buffer (Buffer). It can allocate out-of-heap memory directly using Native function library, and then operate through a DirectByteBuffer object stored in the Java heap as a reference to this memory. This can significantly improve performance in some scenarios because it avoids copying data back and forth between the Native heap and the Java heap.

HotSpot virtual machine object disclosure object creation: (only ordinary Java objects, excluding arrays and Class objects, etc.) when the virtual machine encounters a new instruction, it will first check whether the parameters of this instruction can locate a symbolic reference to a class in the constant pool, and check whether the class represented by this symbolic reference has been loaded, parsed and initialized. If not, you must first perform the corresponding class loading process. After the class load check passes, the virtual machine then allocates memory for the new object. The amount of memory required for an object can be fully determined after the class is loaded, and the task of allocating space for an object is tantamount to dividing a determined-sized piece of memory from the Java heap. Division method: ① pointer collision (Bump the Pointer). If the memory in the Java heap is absolutely regular, with all used memory on one side and idle on the other side, with a pointer in the middle as an indicator of the demarcation point, then allocating memory is simply moving that pointer to the idle side by a distance equal to the size of the object, which is called "pointer collision". Free list (Free List): if the memory in the Java heap is not regular and the used memory and free memory are interlaced, there is no way to simply collide pointers. The virtual machine must maintain a list, record which blocks of memory are available, find a large enough space from the list to allocate to the object instance, and update the records on the list. The choice of allocation method is determined by whether the Java heap is neat or not, and whether the Java heap is neat or not and whether the garbage collector with compression and finishing function is used. Memory allocation method: ① synchronizes the actions of allocating memory space-in fact, the virtual machine uses CAS with a failed retry to ensure the atomicity of the update operation. ② divides the memory allocation into different spaces according to threads, that is, each thread pre-allocates a small piece of memory in the Java heap, which is called local thread allocation buffer (Thread Local Allocation Buffer,TLAB). Whichever thread allocates memory, it is allocated on the TLAB of the thread, and synchronous locking is required only when the TLAB runs out and allocates a new TLAB. After the memory allocation is completed, the virtual machine needs to initialize the allocated memory space to zero (excluding object headers). If TLAB is used, this process can also be advanced to the time of TLAB allocation. This step ensures that the instance fields of the object can be used directly in the Java code without assigning initial values, and the program can access the zero values corresponding to the data types of these fields. Next, the virtual machine needs to set the necessary information on the object, such as which class the object is, how to find the metadata information of the class, the hash code of the object, the GC generation age of the object and so on. This information is stored in the object's Object Header. Depending on the current running state of the virtual machine, such as whether to enable bias locks, the object header will be set in different ways. After all the above work is done, a new object has been created from a virtual machine's point of view, but from the Java's point of view, object creation has just begun-- the method hasn't been executed yet, and all the fields are still zero, so generally speaking, the execution of the new instruction is followed by the method, so that a truly available object is fully generated.

Memory layout of objects: in HotSpot virtual machines, the layout of objects stored in memory can be divided into three areas: object headers (Object Header), instance data (instanceData), and alignment padding (Padding). Object header: the object header includes two parts of information. The first part is used to store the runtime data of the object itself, such as HashCode, GC generational age, lock status flag, lock held by thread, biased thread ID, biased timestamp, and so on. The length of this part of data is 32bit and 64bit in 32-bit and 64-bit virtual machines (without compression pointer on), and officially called "Mark Word". Object needs to store a lot of data, in fact, it has exceeded the limit that 32-bit and 64-bit BitMap structure can record, but object header information is an additional storage cost independent of the data defined by the object itself. Considering the space efficiency of the virtual machine, Mark Word is designed as a non-fixed data structure to store as much information as possible in a very small space. It will reuse its own storage space according to the state of the object. Object access location: the Java program needs to manipulate specific objects on the heap through the reference data on the stack. Because the reference type only specifies a reference to the object in the Java virtual machine specification, it does not define how this reference should locate and access the specific location of the object in the heap, so the object access mode also depends on the virtual machine implementation. At present, the mainstream access methods are the use of handle and direct pointer. If you use handle access, a piece of memory will be allocated in the Java heap to serve as a handle pool. What is stored in the reference is the handle address of the object, and the handle contains the specific address information of the object instance data and the type data. If direct pointer access is used, then the layout of the Java heap object must consider how to place information about the access type data, and the object address is directly stored in reference. These two object access methods have their own advantages: the biggest advantage of ① using handle access is that the stable handle address is stored in reference, which only changes the instance data pointer in the handle pool when the object is moved (it is a very common behavior when moving objects during garbage collection), but reference itself does not need to modify it. The biggest advantage of ② using direct pointer access is that it is faster, which saves the time overhead of pointer positioning.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.