Deep Dive into the storage area of Java objects and elements

When developing an application on the Java platform, an important feature is that the object is created only when the application is running. In other words, when the program runs, the object's ownership will be finally determined, that is, where the object should be stored. Because it is stored in different regions, its performance will be different. Therefore, Java developers need to understand the characteristics of each storage region and its impact on performance. Then adjust the region allocation of the application as needed. In general, there are five places in the operating system that can be used to save the data in the application program running. The characteristics of these regions and their impact on performance are analyzed as follows.

Storage area 1: registers

Although it is in the same memory, its performance varies in different regions for different purposes. For example, for Java applications, the register is in the internal processor, so the fastest data access in this region. It is a world different from other storage areas in the memory. So if we put all the objects in this area, can we improve the performance of Java applications? This is true in theory, but it does not work in reality. Because the number of registers is very limited. The register area in the memory is allocated by the compiler as needed. Our program developers cannot control the register allocation through code. Therefore, we can only look at the first storage region register, without any impact on it.

Storage area 2: Stack

There are two ways to create an object. One is to create an object during application development; the other is to create an object when the object is used during the program running. The former has higher performance than the latter, while the latter is more flexible than the former. This is mainly because the former is created in this stack when an object is created. Although the created object is not stored in the register, the push stack pointer of this object can directly obtain related support from the processor. If the stack pointer moves up, the memory occupied by the original object is released. If the stack pointer moves down, a new memory is allocated to the object. Therefore, if an object is stored in this stack, although the performance is not as good as in the register, it is still much better than storing it elsewhere.

Because Java programs create objects as needed only when the program is running. This object cannot be saved in this stack. However, Java applications cannot waste this precious space. Therefore, although the Java object itself is not saved in this stack (rather than not saved, but there is no place for it), you should put some content that can be stored in this stack, to improve application performance. For example, some object references can be stored in this stack.

In addition, Java programs usually place some basic data type objects in the stack to improve data processing performance. For example, some integer and struct Data Objects have some common characteristics, such as small objects and standard objects provided by Java programs. For these objects, each application basically needs to be used, and our program developers can only reference these objects without making changes to them. For this reason, Java programs often create an object (that is, directly create an object in the stack and save it) at the beginning, instead of creating an object as needed. There is another important reason for creating these objects in the stack. If you create an object in the stack, the Java editor must know the exact size and lifecycle of all data stored in the stack. To obtain this information, you must generate relevant code to obtain this information so that it can operate on the stack pointer. The size and lifecycle of common objects are difficult to obtain in advance. Therefore, creating common objects in the stack is not suitable for Java applications. On the contrary, the size of the predefined objects of the Java compiler does not change with the changes in the hardware architecture and user requirements. These objects often exist at the beginning and end, therefore, there is no life cycle problem. Therefore, it is reasonable and feasible to place these objects in the stack. Such processing will not only affect the flexibility of objects, but also provide better performance.

Storage area 3: heap

Although the heap is the same as the stack, It is a random access to the region in the memory, but the two are very different. Because there is no stack pointer in the heap, it cannot be directly supported from the processor. For this reason, there is a certain gap between its performance and stack. Generally, all objects except the predefined objects mentioned above are stored in the heap. Or, the objects created using the new keyword are stored in the heap. The benefits of saving in the heap are also obvious. For example, the Java compiler does not need to know how many storage regions need to be allocated from the heap or how long the stored data will survive in the heap. Therefore, it is flexible to allocate storage in the heap. When an object is required, we can use the new keyword to create an object. Then, the system automatically assigns an area to the object in the heap to serve as the destination. However, the biggest disadvantage is that it is much slower than creating objects in the heap and allocating storage areas. You can't have both the fish and the bear's paw.

 

Storage Area 4: static storage area and constant Storage Area

Java objects have some special elements. For example, some elements are special (for example, variables defined using the static keyword ). These variables may be static for other objects. To better manage these variables, Java isolates a static storage area in memory to manage these elements. The static storage area is used to store the data that always exists when the application is running at a fixed position. Here, we need to make it clear that Java objects are not stored in this place, but some special elements in the objects are placed here. Because the location is fixed, the next call saves the trouble of searching. Therefore, it is advantageous for providing application performance. As a program developer, when writing code, we need to flexibly apply the static keyword. The author's opinion is that it can be used only when it is usable. When it is unavailable, you should also think about using it. In particular, when some elements do not use the static keyword, it does not affect the function of the program. In this case, we need to add the static keyword before the element.

There is also a special type of elements in Java objects, which are called constants. Because the constant value remains stable, such as the circumference rate. Therefore, it is feasible to put them inside the code. However, sometimes we do not do this when developing embedded systems. Instead, constant elements are separated from the code and saved. For example, we store the constant values in some read-only memory as needed. This is mainly for some special functional considerations. For example, due to copyright control. For example, in order to protect the copyright of the original consumables on the printer, constants and codes are often stored separately.

Storage area 5: Non-ram Storage

Sometimes, the data required for running some programs is stored elsewhere. For example, stream objects need to be used in some systems. The data of this object is not stored in any storage area mentioned above. This object is directly converted to a byte stream, it is sent to another host. Another object called persistence is stored in the hard disk. These objects are not commonly used in application development. You only need to understand the existence of these objects. When necessary, it is not too late to study it in depth.

From the above analysis, we can see that it is difficult for our program developers to control the ownership of objects. Registers are managed by the compiler. The heap and stack are basically restricted by the development platform, and our programmers do not have the ability to interfere with them. In fact, we can mainly adjust and control the fourth storage area, namely static storage and constant storage. The author suggests that static storage should be used whenever possible for non-embedded programs that can be implemented using static storage. For constants, You need to determine whether to store constants in read-only memory based on the functions to be implemented. This read-only memory is sometimes required for copyright protection.