Learning from the Ground up ->JVM (Preface)
Learning from the ground up ->JVM (Preface) – Why delay?
JVM (a) : The Java Memory Model (JMM) is not the Java Virtual Machine memory model (JVM) oh!
Learning from the Ground up – JVM part 2: Why does Java Need a JVM (Java Virtual Machine)?
Learning from the Ground up ->JVM (3) : Classloader (1)
Learning from the Ground up ->JVM (4) : Classloader (Middle)
Learning from the ground up ->JVM (5) : Classloader (2)
Learning from the Ground up – JVM part 6: The Relationship between threads and JVMS
Learning from the ground up ->JVM (7) : Runtime Data Area (1)
Learning from the ground up ->JVM (8) : Runtime Data area (2)
Learning from scratch ->JVM (9) : Garbage Collection (1)
Learning from the ground up ->JVM (10) : Garbage Collection (middle)
Learning from scratch ->JVM (11) : Garbage Collection (2)
preface
Some of the theoretical foundations of garbage collection were covered in my previous article, Learning the JVM from Scratch: Garbage Collection, part 1. This article is about how to implement it in detail.
It is important to note, however, that everything in this article is based on the theory of the previous article, so I highly recommend that you read one article before you read this one, so that you can get a holistic, closed-loop impression of garbage collection.
Of course, if you feel that you have a unique perspective on the theoretical aspects of garbage collection and don’t need my explanation, you can also read this article.
The body of the
Garbage collectors are very complicated, and blogs on the Web talk about them in a very strange way. If you’re not familiar with them, you might wonder what the difference is between the CMS AND Minor gc.
According to the author’s research, the occurrence of these problems is caused by the inaccurate translation of terms in some technical books in China, which leads to some deviations in our understanding of these things. In fact, the so-called CMS GC and Minor GC are completely two different things. In a sense, The CMS is a collector that actually applies to the virtual machine, while the Minor GC is not a garbage collector, but just garbage collection behavior.
Due to the emergence of the idea of generational collection, different garbage collection behaviors are carried out according to different garbage collection algorithms for the new generation and the old generation, and these behaviors are also called GC.
Garbage collection behavior
There are three main types of garbage collection behavior GC:
- Minor GC (also called Yong GC)
- The Major and Full GC
- Mixed GC
Note that the basic logic I am talking about now is the logic in HotSpot VIRTUAL machine, but in the development of Java, there are many different types of virtual machine, different virtual machine, even the same virtual machine but different versions, garbage collection behavior name is different. This has led to a complete confusion in the interpretation of nouns.
What I say is, therefore, is generally noun explanation, different virtual machine of the garbage collector, the garbage collection in new generation and the old s behavior, the term for these garbage collection behavior is different, therefore, in the subsequent interpretation about garbage collection behavior, I will tell a little bit about the other garbage collection behavior of term. But these nouns are basically the same in meaning.
1.Minor GARBAGE Collection
Based on the idea of generational collection, the Memory of the Java heap is divided into multiple regions. Garbage collection can occur in different areas. Our Minor GC refers to garbage collection in the young generation.
Note that in HotSpot, garbage collection in the new generation is also referred to as Yong GC. Different virtual machines and different garbage collectors have different names for this behavior, but in this article, we will refer to this behavior in the new generation as Minor GC.
We all know that the new generation is divided into two regions, the Eden region and the Survivor region, so where does our Minor GC get triggered?
When Eden’s memory is full, GC is triggered!
The Survivor region is divided into two regions, the To Survivor region and the From Survivor region. If the From Survivor region is full, will the Minor GC be triggered?
It should be noted here that Minor GC is triggered only when the Eden region is full, that is, when the From Survivor region is full, Minor GC is not triggered either.
The thing to understand is, why is that? Won’t you run out of memory by doing this? A closer look at Minor’s entire collection behavior shows why the JVM does this.
Basically, all objects are born in Eden, and all objects From Survivor are copied From Eden.
That is, when the Eden region is full, a Minor GC is triggered To copy surviving objects in the Eden region and surviving objects in the From Survivor region To the To Survivor region, and then clean up the Eden region and From Survivor region.
So what happens when we copy and find that the To Survivor zone doesn’t hold enough objects?
The JVM has a number of optimizations here, as follows:
- First, MinorGC again intends To reclaim the unreferenced data From Surviovr and move the referenced data To To Survivor. If To Survivor is sufficient, From Surviovr is cleared; If To Survivor is full, the data just saved To Survivor is rolled back, the GC data is saved directly To the old age via the space allocation guarantee mechanism, and From Surviovr remains as it was when MinorGC was created.
- If the JVM’s adaptive switch is set, the new generation size will be adjusted after the Minor GC ends.
- The JVM has set some optimizations so that if the Eden region is full, the Minor GC will not necessarily be triggered, but rather will simply new the object to the old age.
As you can see from the above statement, the garbage collection algorithm that our Minor GC uses is the mark-copy algorithm, which we parsed in our previous article “Learning JVM from Scratch: Garbage Collection (part 1)” and won’t repeat here.
2.Major GC and Full GC
Major GC refers to garbage collection in the old days.
Different garbage collectors, however, have different names for the old garbage collection behavior, but only the CMS garbage collector, will have a special old garbage collector for the old garbage collection, usually called the Major garbage collector, but if other garbage collectors, for the old garbage collection, Both use Full GC (except the G1 garbage collector), and the Major GC only collects old ages, whereas Full GC collects the entire Java heap. (This happens because there are too many virtual machines and garbage collectors in the industry, and many terminology standards are not unified.)
In HotSpot, this garbage collection behavior is called Old GC, so only the CMS garbage collector actually names this garbage collection behavior Major GC, but to better understand this garbage behavior, in this article, we will refer to the Old garbage collection behavior as Major GC. (It is important to note, however, that the garbage collection algorithm is different for different GC’s, such as the mark-clean algorithm for the Major GC and the mark-clean algorithm for the Full GC.)
In fact, this garbage collection behavior is also described in the previous article, Learning THE JVM from the Ground up: The Runtime Data area (part 2), when I talked about the runtime data area Java heap, and I will talk about it again.
The triggering of a Major GC has a strong correlation with the Minor GC.
Before a Minor GC occurs, the virtual machine checks whether the maximum available contiguous space of the old generation is greater than the total space of all objects of the new generation. If so, the Minor GC is safe. If less, the virtual machine checks the HandlePromotionFailure setting to see if the guarantee failure is allowed.
If HandlePromotionFailure=true, it continues to check if the maximum contiguous available space of the old age is greater than the average size of the objects promoted to the old age, and if so, a Minor GC is attempted, but this Minor GC is still risky; If less than or HandlePromotionFailure=false, do a Major GC instead.
This is often referred to as the JVM’s space allocation guarantee.
However, the trouble is that the CMS garbage collector I described above would be the same, while any other garbage collector would use the Full GC to collect the entire heap, and the natural collection area would also include older generations. One exception to this is the G1 garbage collector, which in its old days was collected using the Mixed GC.
The Full GC definition is relatively unambiguous, and is a global scope GC for the entire Cenozoic, old-age, metaspace (java8 + instead of permanent generation).
3.Mixed GC
Mixed GC is a garbage collection behavior that collects the entire new generation and part of the old generation. Only the G1 has this mode.
Because G1 garbage collector, it is our Java heap split into many small pieces of memory, these blocks of memory called the region, and therefore, although the G1 garbage collection still follows the generational collection theory, but the garbage collection is not confined to a new or old age, but extended to the entire Java heap.
Instead of insisting on fixed size and fixed number of generational regions, G1 uses not only the generational collection idea, but also the partitioning collection idea. Instead, it divides the contiguous Java heap into independent regions of equal size, each of which can act as the Eden space of the new generation, Survivor space, or old chronospace, as needed.
The Mixed GC will only select all the regions of the young generation and some old regions with high collection benefits for collection, not all the old regions. When collecting regions belonging to the old era, the system considers which memory blocks store the most garbage and collect the most revenue.
G1 will figure out which objects need to be recycled, and this process is quite lengthy. When G1 determines that there are objects in a region that need to be reclaimed, it copies the remaining objects in the region to other blank regions and clears the region.
That is, the garbage collection algorithm used by the Mixed GC is a mark-copy algorithm from the point of view of a local region. But in the context of the entire Java heap, the garbage collection algorithm used is mark-collation. However, no memory fragmentation is generated, which also ensures that there is complete free memory after garbage collection is complete, which is beneficial to the long-term running of the program.
conclusion
For our garbage collection behaviors, we will define these behaviors as a GC, but this is not a garbage collector, this is just a garbage collection behavior, which I will cover in the next article.
For the so-called Minor, Major, Full and Mixed GC, I believe that those who have read this article have a good understanding of classification and understanding.
However, it is important to note that the Java virtual machine world is so vast that there are many virtual machines that use other standards to collect garbage. What I describe in this article is our official virtual machine garbage collection behavior, not the entire Java virtual machine world.