One advantage of Java is Garbage Collection (GC), which helps us manage memory, but stops the World when it works. Stop all worker threads and say, “You guys stop working while I clean up the garbage!” .
If you’re playing a game, the computer STW for a few seconds to clean up the trash. You might ****, and your teammates might ***.
However, some of the most common garbage collectors now require STW, and although various garbage collectors have been racking their brains to reduce STW time, they cannot avoid STW. A detailed comparison of the various garbage collectors is a separate article for next time.
Today we’ll start by looking at how GC quickly enumerates root nodes. In the HotSpot VIRTUAL machine, reachable analysis is used to determine whether the object needs to be recycled. Reachable analysis requires finding the “source,” or root node.
By enumerating one root at a time (GC Roots) and then working your way down, the untouched objects snap it back. That this follow the process must let the world stop, that is, those working threads have to stop, you think if you don’t STW that object reference relationship changed to change, garbage collector how to click objects ah, easy to click the wrong, that we users are not urgent. Therefore, when enumerating root nodes, STW is unavoidable, so keep STW as short as possible.
The root node is primarily in global references (constants, class static attributes) and execution context (local variables in stack frames). Well, it’s gonna be slow if we have to go through them one by one. And our HotSpot is the accuracy GC, which means it needs to know the type of data at a location, and the type is accurate. This way it knows exactly if the data type is a pointer that it cares about.
In HotSpot, a structure called OopMap is used to store what types of data are on what offsets within an object. This is recorded during class loading. OopMap can be thought of as an additional piece of information, or a tag on a piece of clothing, which tells us what the clothing is made of. So when GC is scanning, it can directly see these “tags” to know the information.
JIT compilation also records oOPMaps at specific locations. It records where references are placed on the stack and in registers when an instruction to the method is executed. Each method may have several OOPMaps, depending on the location, which splits the method into several pieces. Each one has an OopMap.
These specific locations are mainly in:
1. Before the method returns/after the call instruction of the method is called
2. The end of the loop
3. Where an exception might be thrown
These specific locations are also called safepoints.
The reason for recording OopMap at a specific location is that recording every instruction requires a lot of space, raising the space cost of GC, so using a few key points to record can effectively reduce the space required for recording.
So GC doesn’t come anytime, anywhere, and can only be started when a safe point has been reached.
OopMap is usually compressed in memory, unpacked only when GC is needed, and then traversed to scan the offset.
For JNI(Java Native Interface) methods, there is no OopMap because the Native method has nothing to do with the interpreter or JIT compiler. It’s referring to the same thing as the middle layer, which is the handle, which means that instead of referring directly to an object in the heap, the reference points to a handle, and the handle points to an object in the heap. So GC simply scans the handle without scanning the stack frame.
If there are mistakes welcome to correct! Personal public account: Yes training level guide