This fact is not deducible from static analysis, and yet when we measure the runtime
behavior of software, we see that it is broadly true across a wide range of workloads.
The HotSpot JVM has a garbage collection subsystem that is designed specifically to
take advantage of the weak generational hypothesis, and in this section, we will dis‐
cuss how these techniques apply to short-lived objects (which is the majority case).
This discussion is directly applicable to HotSpot, but other server-class JVMs often
employ similar or related techniques.
In its simplest form, a generational garbage collector is simply one that takes notice
of the WGH. They take the position that some extra bookkeeping to monitor mem‐
ory will be more than paid for by gains obtained by being friendly to the WGH. In
the simplest forms of generational collector, there are usually just two generations—
usually referred to as young and old generation.
In our original formulation of mark and sweep, during the cleanup phase, we
reclaimed individual objects, and returned their space to the free list. However, if
the WGH is true, and on any given GC cycle most objects are dead, then it may
make sense to use an alternative approach to reclaiming space.
This works by dividing the heap up into separate memory spaces. Then, on each GC
run, we locate only the live objects and move them to a different space, in a process
called evacuation . Collectors that do this are referred to as evacuating collectors —
and they have property that the entire memory space can be wiped at the end of the
collection, to be reused again and again. Figure 6-3 shows an evacuating collector in
Figure 6-3. Evacuating collectors