82.JAVA Programming Ideas--about garbage collection

82.JAVA Programming Ideas--about garbage collection

"It's hard to believe that Java can be as fast as C + + and even faster. ”

According to my own practice, this assertion is true. However, I also find that many of the doubts about speed come from early implementations. Because these methods are not particularly effective, there is no model for reference, and the reason for the fast Java speed cannot be explained.

Part of the reason for thinking about speed is due to the C + + model. C + + puts its main focus on everything that happens during compilation, so the runtime version of the program is very short and fast. C + + is also directly based on the C model (mainly for backwards compatibility), but sometimes it is the most convenient method in C + + because it can work in a specific way. One of the most important things is how C and C + + manages memory, which is an important basis for some people to think that Java speed must be slow: in Java, all objects must be created in the memory heap.

In C + +, objects are created in the stack. This speeds up faster because when we enter a specific scope, the stack pointer moves down one unit, allocating storage space for all stack-based objects created within that scope. When we leave the scope (after all the local builders have been called), the stack pointer moves up one unit. However, it is usually much slower to create a heap object in C + + because it is built on the memory heap of C. This heap of memory is actually a large memory pool that requires recycling (regeneration). When you call Delete in C + +, the freed memory leaves a hole in the heap, so when you call new, the storage allocation mechanism must do some sort of search to make the object's storage match any existing hole in the heap, otherwise it will quickly run out of storage space on the heap. The allocation of memory heaps is such a significant performance impact on performance in C + + that searching for available memory is an important reason. So it's much faster to create a stack-based object.

Similarly, because C + + has so much work to do during compilation, this is a factor that must be considered. But in some parts of Java, things happen to be "dynamic", and it changes the model. When creating objects, the use of garbage collectors has a significant impact on the speed of object creation. On the face of it, it seems strange that the release of storage space will affect the allocation of storage space, but it is one of the important tools that the JVM takes, which means that allocating storage space for heap objects in Java is almost as fast as creating storage space on the stack in C + +.

You can think of the C + + heap (and the slower Java heap) as a courtyard in which each object has its own piece of land. At some later time, this "real estate" will be abandoned and must be regenerated. But in some JVMs, the Java heap works quite differently. It's more like a conveyor belt: each time a new object is assigned, it moves forward. This means that the allocation of the object storage space can be very fast. The heap pointer moves simply forward to Virgin territory, so it is almost identical to the stack allocation of C + + (of course, it costs a bit more on data logging, but much faster than searching for storage space).

Now, you may notice that the heap of facts is not a conveyor belt. If you treat it that way, you end up requiring a lot of paging (which can have a huge impact on performance), which will eventually run out of memory and memory paging errors. So there has to be a trick here: the famous "garbage collector". While collecting "garbage", it is also responsible for compressing all objects in the heap, moving the "heap pointer" to where it is as close to the beginning of the conveyor as possible, away from the place where (memory) the paging error occurred. The garbage collector will rearrange everything to make it a high-speed, infinitely free heap model, with the ease of allocating storage space.

To really master how it works, we first need to understand the work scenarios that different garbage collectors (GC) take. A simple, but slow, GC technique is a reference count. This means that each object contains a reference counter. Whenever a handle is connected to the same object, the reference counter adds value. Whenever a handle exceeds its scope or is set to NULL, the reference count is reduced. This way, as long as the program is running, reference count management is required continuously-although the overhead of this management itself is relatively small. The garbage collector moves through the entire list of objects, and once it finds that one of the reference counts becomes 0, it frees up the storage space it occupies. But this also has a drawback: if the object is circular reference to each other, then even if the reference count is not 0, it is still possible to belong to the "garbage" receivable. In order to find this self-referencing group, the garbage collector is required to do a lot of extra work. A reference count is a type of garbage collection, but it does not look suitable for use in all JVM scenarios.

In faster scenarios, garbage collection is not based on reference counting. Instead, they are based on the principle that all non-deadlocked objects will eventually be able to trace back to a handle that either exists on the stack or exists in a static storage space. This backtracking chain may have gone through several layers of objects. So, if you start from a stack and a static storage area and go through all the handles, you can find all the active objects.

For each handle that you find, you must trace to the object it points to, then follow all the handles in that object, "track Chase" to the object they point to?? Wait until you have traversed the entire network of links originating from a handle in the stack or static storage area. Each object that has been moved halfway must still be active. Note For those special self-referencing groups, the aforementioned issues do not occur. Because they are not found at all, they are automatically treated as garbage.

In the approach described here, the JVM uses an "adaptive" garbage collection scheme. For those active objects it finds, the action taken depends on what variant is currently in use. One of the variants is stop and copy. This means that the program will first stop running (not a background collection scenario) because of some very obvious reasons in the near future. Each of the found active objects is then copied from one memory heap to another, leaving all the garbage. In addition, as objects are copied to the new heap, they are focused one by one. This makes the new heap more compact (and makes the new storage area simple to pull away from the end, as described earlier).

Of course, when you move an object from one place to another, all the handles (references) that point to that object must change. The handles that are obtained for objects that are tracked by the memory heap, as well as those static storage areas, can be changed immediately. However, during the traversal process, it is possible to encounter other handles to this object. Once the problem is discovered, it is immediately corrected (imagine a hash table mapping the old address to a new address).

Two aspects of the problem make the replication collector appear inefficient. The first problem is that we have two heaps, all of which are moving back and forth in these two separate heaps, requiring more than twice times the amount of management that is actually needed. To solve this problem, some JVMs allocate a heap of memory as needed and simply copy one heap to another.

The second problem is replication. As programs become more and more "robust", it produces little or no litter. However, one replica collector will still replicate all memory from one place to another, which is wasteful. To avoid this problem, some JVMs can detect whether new garbage has been generated and then change the alternative (which is the "adaptive" reason). Another scenario, known as "tagging and clearing," is what Sun's JVM has been using. For conventional applications, marking and purging is very slow, but once you know that you are not producing garbage, or just producing very little garbage, it can be very fast.

Markup and purge take the same logic: start with a stack and a static storage area, and track all the handles to find the active object. However, each time an active object is found, a marker is set to "Mark" the object. But that object is not collected at this time. The purge process is only formally started when the tagging process is complete. During the purge process, the deadlock object is released however, no form of replication is made, so if the collector decides to compress a discontinuous memory heap, it is implemented by moving the surrounding objects.

Stop and copy shows us that this type of garbage collection does not occur in the background, and that, in the event of garbage collection, the program stops running. In Sun's document library, it is found that garbage collection is defined as a low-priority background process in many places, but it is only a theoretical experiment that actually does not work at all. In practical applications, Sun's garbage collector runs when memory is reduced. In addition, "Mark and clear" also requires the program to stop running.

As noted earlier, in the JVM described here, memory is allocated in chunks. If you assign a big object, it will get its own block of memory. Strict stop and copy requires that you copy each active object from the source heap to a new heap before releasing the old heap, which involves a lot of memory conversion work. With a block of memory, the garbage collector can usually use the dead block to replicate objects as if it were collected. Each block has a build count that keeps track of whether it is still "alive". Typically, only blocks created since the last garbage collection are compressed, and for all other blocks, if references have been made from some other place, the build count overflows. This is a situation that many short-term, temporary objects often encounter. Will periodically perform a complete cleanup-the bulky objects are still not duplicated (just let their build count overflow), and those containing small objects are copied and compressed. The JVM monitors the efficiency of the garbage collector, and if the garbage collection becomes a waste of time because all objects belong to long-term objects, it switches to the "Mark and purge" scenario. Similarly, the JVM tracks the successful "Mark and clear" work of monitoring, and if the memory heap becomes more and more "fragmented", the "Stop and copy" scenario is swapped back. The word "Custom" is from this behavior, and we summarize it as follows: "Automatically convert stop and copy/Mark and clear both modes as appropriate."

The JVM also uses many other acceleration scenarios. One of the particularly important concerns is the loader and the JIT compiler. If you have to load a class (usually the first time we want to create an object of that class), we will find the. class file and send the byte code of that class into memory. At this point, one method is to JIT compile all the code, but there are two drawbacks: it will take more time, if the program's running time is considered, the compilation time may be longer, and it increases the length of the execution file (byte code is much more streamlined than the extended JIT code), which may cause memory page exchange, This significantly slows down the execution speed of a program. Another alternative is to not JIT-compile unless it is necessary. In this way, code that is not executed at all may never get JIT-compiled.

Because the JVM is external to the browser, you may want to benefit from some JVM speed improvements when using the browser. Unfortunately, the JVM is currently unable to communicate with different browsers. To exploit the potential of a particular JVM, either use a browser built into that JVM, or run a standalone Java application.

82.JAVA Programming Ideas--about garbage collection