Java Reference
In-Depth Information
This is potentially much more efficient than the naive collection approach, because
the dead objects are never touched. GC cycle length is proportional to the number
of live objects, rather than the number of allocated objects. The only downside is
slightly more bookkeeping—we have to pay the cost of copying the live objects, but
this is almost always a very small price compared to the huge gains realized by evac‐
uation strategies.
HotSpot manages the JVM heap itself, completely in user
space, and does not need to perform system calls to allocate or
free memory. The area where objects are initially created is
usually called Eden or the Nursery, and most production
JVMs (at least in the SE/EE space) will use an evacuating strat‐
egy when collecting Eden.
The use of an evacuating collector also allows the use of per-thread allocation. This
means that each application thread can be given a contiguous chunk of memory
(called a
thread-local allocation bufer
) for its exclusive use when allocating new
objects. When new objects are allocated, this only involves bumping a pointer in the
allocation buffer, an extremely cheap operation.
If an object is created just before a collection starts, then it will not have time to ful‐
fill its purpose and die before the GC cycle starts. In a collector with only two gener‐
ations, this short-lived object will be moved into the long-lived region, almost
immediately die, and then stay there until the next full collection. As these are a lot
less frequent (and typically a lot more expensive), this seems rather wasteful.
To mitigate this, HotSpot has a concept of a
survivor space
—this is an area that is
used to house objects that have survived from previous collections of young objects.
A surviving object is copied by the evacuating collector between survivor spaces
until a
tenuring threshold
is reached, when the object will be
promoted
to the old
generation.
A full discussion of survivor spaces and how to tune GC is outside the scope of this
topic—for production applications, specialist material should be consulted.
y
y
d
The HotSpot Heap
The HotSpot JVM is a relatively complex piece of code, made up of an interpreter
and a just-in-time compiler, as well as a user-space memory management subsys‐
tem. It is comprised of a mixture of C, C++, and a fairly large amount of platform-
specific assembly code.
At this point, let's summarize our description of the HotSpot heap, and recap its
basic features. The Java heap is a contiguous block of memory, which is reserved at
JVM startup, but only some of the heap is initially allocated to the various memory
