occupied after the collection. The entire process took 0.12 seconds, though the parallel GC
threads racked up 0.42 seconds in CPU usage.
A concurrent cycle is shown in Figure 6-5 .
The JVM starts a concurrent cycle based on the occupancy of the heap. When it is suffi-
ciently full, the JVM starts background threads that cycle through the heap and remove ob-
jects. At the end of the cycle, the heap looks like the bottom row in this diagram. Notice that
the old generation is not compacted: there are areas where objects are allocated, and free
areas. When a young collection moves objects from eden into the old generation, the JVM
will attempt to use those free areas to hold the objects.
Figure 6-5. Concurrent collection performed by CMS
In the GC log, this cycle appears as a number of phases. Although a majority of the concur-
rent cycle uses background threads, some phases introduce short pauses where all application
threads are stopped.
The concurrent cycle starts with an initial mark phase, which stops all the application
89.976: [GC [1 CMS-initial-mark: 702254K(1398144K)]
772530K(2027264K), 0.0830120 secs]
[Times: user=0.08 sys=0.00, real=0.08 secs]