Table 6-2 Fields Captured in GC Log Data When Using -Xverbosegcprint options (continued)

—3: Incremental collection will fail

—4: Linear allocation will fail

—5: Anticipated promotion

—6: Incremental CMS garbage collection

and m indicates the background CMS state when yielding, as follows:

—0: Resetting

—1: Idling

—2: Initial marking

—3: Marking

—4: Final marking

—5: Pre-cleaning

—6: Sweeping

—7. Abortable pre-cleaning

•When %1 is equal to 11, %2 indicates the stop-the-world phase of CMS GC, as follows:

—2: Initial marking (first stop-the-world phase)

—4: Final marking (second stop–the-world phase)

%3 Program time at the beginning of the collection, in seconds

%4 Garbage collection invocation. Counts of background CMS garbage collections and other garbage collections are maintained separately

%5 Size of the object allocation request that forced the GC, in bytes

%6 Tenuring threshold - memory allocation that determines how long newborn objects remain in the new generation, in bytes. These spaces are reported:

•Occupied before garbage collection (Before)

•Occupied after garbage collection (After)

•Current capacity (Capacity)

%7, Eden sub-space within the new generation, in bytes. These spaces are reported:

%8, • Before

%9 • After

•Capacity

%10, Survivor sub-space within the new generation, in bytes. These spaces are reported: %11,%12 • Before

•After

•Capacity

%13, Old generation, in bytes. These spaces are reported:

%14, • Before

%15 • After

•Capacity

%16, Permanent generation, in bytes. These spaces are reported for storage of reflective objects:

%17, • Before

%18 • After

•Capacity

%19 Total stop-the-world duration, in seconds.

%20 Total time used in collection, in seconds.

82 Analyzing Garbage Collection Data