|
Problem(Abstract) |
What are pinned objects in Java™ and how can you avoid
fragmentation? |
|
|
|
Cause |
Objects that are on the Java heap are usually mobile, that
is, the garbage collector (GC) can move them around if it decides to
resequence the heap. Some objects, however, cannot be moved either
permanently or temporarily. Such immovable objects are known as
pinned objects. |
|
|
Resolving the
problem |
In the Java SDK Release 1.3.1 Service Refresh 7 and above:
- The GC allocates a kCluster as the first object at the bottom of the
heap. A kCluster is an area of storage that is used exclusively for class
blocks. It is large enough to hold 1280 entries. Each class block is 256
bytes long.
- The GC then allocates a pCluster as the second object on the heap. A
pCluster is an area of storage that is used to allocate any pinned
objects. It is 16 KB long.
- When the kCluster is full, the GC allocates class blocks in the
pCluster.
- When the pCluster is full, the GC allocates a new pCluster of 2 KB.
Because this new pCluster can be allocated anywhere in the heap and must
be pinned, it can cause fragmentation problems.
How does fragmentation occur?
The pinned objects deny the GC the ability to combine free space during
heap compaction; this can result in a heap that contains a lot of free
space but in relatively small, discrete amounts, so that an allocation
that appears to be well below the total free heap space fails.
How to avoid fragmentation
Java SDK Release 1.3.1 at SR7, and later, provides command-line options to
specify the size of:
- kCluster: -Xk
- pCluster: -Xp
- pCluster overflowsize: -Xp
Use these options to set the initial sizes of the clusters large enough to
avoid fragmentation issues.
For a large Java application, such as WebSphere® Application Server, the
default kCluster space might not be sufficient to allocate all
classblocks.
Example
Garbage collection output:
<GC(VFY-SUM): pinned=4265(classes=3955/freeclasses=0) dosed=10388
movable=1233792 free=5658>
What is the garbage collector doing?
The pinned and class sizes are about the right size needed for the -Xk
parameter. IBM recommends that you add 10% to the reported value (3955).
In this example, -Xk4200 is a good setting. The difference between pinned
(=4265) and classes (=3955) provides a guide for the initial size of
pCluster; however, because each object might be a different size, it is
difficult to predict the requirements for the pCluster and pCluster
overflow options.
- Set -Xk to handle object up to the specified size.
-Xknnnn
where nnnn specifies the maximum number of classes the
kCluster can contain.
-Xk instructs the JVM to allocate space for nnnn class blocks in
kCluster. GC trace data obtained by setting -Xtgc2 provides a guide for
the optimum value of the nnnn parameter. You must keep -Xtgc2
enabled until fragmentation is avoided.
- Specify the pCluster and pCluster overflow sizes using the
-Xp command-line option.
-Xpiiii[K][,oooo[K]]
where iiii specifies the size of the initial pCluster in KB
and oooo optionally specifies the size of overflow (subsequent)
pClusters in KB. Default values of iiii and oooo are 16 KB
and 2 KB respectively . If your application suffers from heap
fragmentation, use GC trace and specify the -Xk option.
If the problem persists, experiment with higher initial pCluster settings
and overflow pCluster sizes.
IBM
HeapAnalyzer can provide recommended kCluster size from Java heap
dumps. IBM Pattern
Modeling and Analysis Tool for Java Garbage Collector can provide more
accurate recommendations on kCluster size from verbose garbage collection
trace with -Xtgc2 enabled. |
|
|
|