Java Reference
In-Depth Information
Allocating Large Objects
This section describes in detail how the JVM allocates objects. This is interesting back-
ground information, and it is important to applications that frequently create a significant
number of large objects. In this context, “large” is a relative term; it depends, as we'll see, on
the size of a TLAB within the JVM.
TLAB sizing is a consideration for all GC algorithms, and G1 has an additional considera-
tion for very large objects (again, a relative term—but for a 2 GB heap, objects larger than
512 MB). The effects of very large objects on G1 can be very important—TLAB sizing (to
overcome somewhat large objects when using any collector) is fairly unusual, but G1 region
sizing (to overcome very large objects when using G1) is more common.
Thread-local allocation buffers
Chapter 5 discusses how objects are allocated within eden; this allows for faster allocation
(particularly for objects that are quickly discarded).
It turns out that one reason allocation in eden is so fast is that each thread has a dedicated re-
gion where it allocates objects—a TLAB. When objects are allocated directly in a shared
space, some synchronization is required to manage the free-space pointers within that space.
By setting up each thread with its own dedicated allocation area, the thread needn't perform
any synchronization when allocating objects. (This is a variation of how thread-local vari-
ables can prevent lock contention [see Chapter 9 ] .)
Usually, the use of TLABs is transparent to developers and end users: TLABs are enabled by
default, and the JVM manages their sizes and how they are used. The important thing to real-
ize about TLABs is that they have a small size, so large objects cannot be allocated within a
TLAB. Large objects must be allocated directly from the heap, which requires extra time be-
cause of the synchronization.
As a TLAB becomes full, objects of a certain size can no longer be allocated in it. At this
point, the JVM has a choice. One option is to “retire” the TLAB and allocate a new one for
the thread. Since the TLAB is just a section within eden, the retired TLAB will be cleaned at
the next young collection and can be reused subsequently. Alternately, the JVM can allocate
the object directly on the heap and keep the existing TLAB (at least until the thread allocates
additional objects into the TLAB). Consider the case where a TLAB is 100 KB, and 75 KB
has already been allocated. If a new 30 KB allocation is needed, the TLAB can be retired,
which wastes 25 KB of eden space. Or the 30 KB object can be allocated directly from the
heap, and the thread can hope that the next object that is allocated will fit in the 25 KB of
space that is still free within the TLAB.
Search WWH ::




Custom Search