Java Reference
In-Depth Information
When a new object does not fit in the current TLAB (but would fit within a new, empty
TLAB), the JVM has a decision to make: whether to allocate the object in the heap, or
whether to retire the current TLAB and allocate a new one. That decision is based on several
parameters. In the TLAB logging output, the refill waste value gives the current
threshold for that decision: if the TLAB cannot accommodate a new object that is larger than
that value, then the new object will be allocated in the heap. If the object in question is smal-
ler than that value, the TLAB will be retired.
That value is dynamic, but it begins by default at 1% of the TLAB sizeā€”or, specifically, at
the value specified by -XX:TLABWasteTargetPercent = N . As each allocation is done outside
the heap, that value is increased by the value of -XX:TLABWasteIncrement= N (the default is
4). This prevents a thread from reaching the threshold in the TLAB and continually allocat-
ing objects in the heap: as the target percentage increases, the chances of the TLAB being re-
tired also increases. Adjusting the TLABWasteTargetPercent value also adjusts the size of
the TLAB, so while it is possible to play with this value, its effect is not always predictable.
Finally, when TLAB resizing is in effect, the minimum size of a TLAB can be specified with
-XX:MinTLABSize= N (the default is 2 KB). The maximum size of a TLAB is slightly less
than 1 GB (the maximum space that can be occupied by an array of integers, rounded down
for object alignment purposes) and cannot be changed.
1. Applications that allocate a lot of large objects may need to tune the TLABs
(though often using smaller objects in the application is a better approach).
Humongous objects
Objects that are allocated outside a TLAB are still allocated within eden when possible. If
the object cannot fit within eden, then it must be allocated directly in the old generation. That
prevents the normal GC lifecycle for that object, so if it is short-lived, GC is negatively af-
fected. There's little to do in that case other than change the application so that it doesn't
need those short-lived huge objects.
Humongous objects are treated differently in G1, however: G1 will allocate them in the old
generation if they are bigger than a G1 region. So applications that use a lot of humongous
objects in G1 may need special tuning to compensate for that.
Search WWH ::

Custom Search