Java垃圾收集：次要，主要，完整

Question

I am trying to get a hang on garbage collection in a large enterprise Java application. I have the GC logs and started looking into them using various tools - the screenshot here is done using GCViewer . (Sadly there is no logs with more verbose GC info...)

I was also reading up on the Java Hotspot VM garbage collection, which we are using.

But I am still somewhat confused: below is a screenshot of a zoomed in section of the GC graph.

There are three things going on here:

1. There is the "small zigzag" of the blue line (which you can hardly see): from what I understand these are minor gc cycles happing in Young space.

2. There is the black bar, which is a blocking 10s full GC, as can be seen in the logs:

    1751585.394: [Full GC 1433326K->660045K(1552832K), 10.1157600 secs] 

3. Then there is the "big zigzag" of the blue line (manifesting in the drop on the left). This is what confuses me.

The logs for pattern #3 don't mark it as full GC, but look similar to the rest...

    1749795.648: [GC 1299871K(1552832K), 0.0402933 secs]

• So is this a minor GC as well?
• If yes, why are there two different patterns of minor garbage collects happening at the same time (#1 and #3)?
• Or is there something else between minor GC in Young space and full GC in Tenured?

---

Edit. Some additional info:
GC used: Concurrent Mark-Sweep GC
Throughput is 93.8 %
Longest Pause: 10.116 seconds
Time Paused: 6.21%

Answer 1

Java's generational garbage collector has several different "kinds" of garbage collection. As you mentioned, the "small zig-zags" are minor collections in the young space, and the black bar would be a full garbage collection. For the sake of simplicity, I'll just describe the most important parts of what's happening.

The young generation is divided into an "Eden" space one or more "survivor" spaces. During one of those small zig-zags, dead objects in the Eden space are removed, and live objects are moved to one of the survivor spaces. This is a very quick operation, because the weak generational hypothesis states that most objects will be short-lived. A subsequent sweep of the survivor space may move objects that are still alive from the survivor space into the tenured generation. This is still considered a minor collection.

I suspect what you see in the first big drop is actually a "promotion" from the survivor generations to the tenured generation.

The tenured generation is everything that is not young enough to be in the young generation (what this means, like many other GC options, is tuneable). The tenured generation is much larger than the young generation, and therefore takes a lot of time to sweep. When you talk about a "full" garbage collection, this refers to a sweep of the tenured generation (in addition to the young generation).

The CMS garbage collector operates concurrently for most of the things it does, but still needs to stop the world for the mark operations on the young and tenured generations. The CMS collector is supposed to be very quick at this, even for large heaps. However, there's one other situation where CMS stops the world: concurrent mode failure .

The second big drop with the pause may have been a result of this, which occurs when the tenured generation is too full. You can adjust the size of the tenured generation and other parameters to avoid these.

Answer 2

I doubt this is a concurrent-sweep. To confirm, must monitor with following

-verbose:gc -XX:+PrintGCDetails

And assuming the graph is showing young + tenured generation, this cannot be a promotion from the survivor generations to the tenured generation as Jonathan has mentioned.

Answer 3

Based on the logs you have, I would say:

1) this is a minor collection. As @Eugene says above, it is short and it is not labelled as a full-gc.

2) there are two sorts of short-lived objects in your application at this point. Some very short-lived ones which "last" the amount of time between 2 of those small zigzags. And some longer-lived ones, which still do not last long enough to be promoted to the tenured generation, and which become eligible for gabage-collection at some point before the confusing minor-collection.

There may be other explanation but I don't believe you can tell that from what you have.

If you are concerned by it (or maybe if you are just curious) I would enable more detailed gc logging, and use logs like your access-logs to try and correlate application activity with the drop.