CPU time than real time because the young collection was done by multiple threads (in this
configuration, four threads).
Figure 6-2 shows the heap before and after a full GC.
Figure 6-2. A throughput full GC
The old collection frees everything out of the young generation (including from the survivor
spaces). The only objects that remain in the old generation are those which have active refer-
ences, and all of those objects have been compacted so that the beginning of the old genera-
tion is occupied, and the remainder is free.
The GC log reports that operation like this:
64.546: [Full GC [PSYoungGen: 15808K->0K(339456K)]
[ParOldGen: 457753K->392528K(554432K)] 473561K->392528K(893888K)
[PSPermGen: 56728K->56728K(115392K)], 1.3367080 secs]
[Times: user=4.44 sys=0.01, real=1.34 secs]
The young generation now occupies 0 bytes (and its size is 339 MB). The data in the old
generation decreased from 457 MB to 392 MB, and hence the entire heap usage has de-
creased from 473 MB to 392 MB. The size of permgen is unchanged; it is not collected dur-
ing most full GCs. (If permgen runs out of room, the JVM will run a full GC to collect perg-
men, and you will see the size of permgen change—which is the only way to detect if perm-