|
| Problem | What are pinned objects in the Java™ and how you can avoid fragmentation? | | | | Solution | Objects that are on the Java heap are usually mobile; that is, the garbage collector 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.
In release 1.4.0 and above, the garbage collector 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 garbage collector 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 garbage collector allocates class blocks in the pCluster. When the pCluster is full, the garbage collector allocates a new pCluster of 2 KB. Because this new pCluster can be allocated anywhere, it can cause problems.
To remove these problems, release 1.4.1 uses a pinnedFreeList, which changes the way in which the pCluster is allocated. The concept is that after every garbage collection, the garbage collector takes an amount of storage from the bottom of the free list and chains it from the pinnedFreeList. Allocation requests for pClusters use the pinnedFreeList, while other allocation requests use the free list. When either free list is exhausted, the garbage collector causes an allocation failure and a garbage collection. This action ensures that all pClusters are allocated in the lowest-available storage location in the heap.
The garbage collector uses this algorithm to determine how much storage to put on the pinnedFreeList:
- The initial allocation is for 50 KB.
- If this is not the initial allocation and the pinnedFreeList is empty, the garbage collector allocates 50 KB or five times the amount of allocations from the clusters since the last garbage collection, whichever is the larger.
- If this is not the initial allocation and the pinnedFreeList is not empty, the garbage collector allocates 2 KB or five times amount of allocations from the clusters since the last garbage collection, whichever is the larger.
This algorithm increases the amount of storage that is available when the application is loading many classes. It therefore avoids an allocation failure that is due to an exhausted pinnedFreeList. It also reduces the amount of storage that is on the pinnedFreeList when little allocation of pinned clusters exists, and therefore avoids the need to remove large amounts of storage from the free list.
The buildPinnedFreeList function builds the pinnedFreeList by using the above algorithm. This function is called from the following places:
- In initializeClusters
- At the end of expandHeap
- At the end of gc0_locked
The garbage collector makes allocations from the pinnedFreeList by calling the nextPinnedCluster function. This function works in a way that is similar to the way in which nextTLH works; that is, it always takes the next available free chunk on the pinnedFreeList. If the pinnedFreeList is empty, it calls manageAllocFailure.
In realObjCAlloc, if no room remains in the clusters, the garbage collector calls nextPinnedCluster to allocate a new pCluster.
In initializeClusters, the garbage collector calls nextPinnedCluster, which allocates an initial pCluster of 50 KB because 50 KB is the size of the only free chunk that is on the pinnedFreeList. The free chunk has that size because the pinnedFreeList had the initial allocation of 50 KB.
For a large Java application, such as WebSphere® Application Server, the default kCluster space might not be sufficient to allocate all classblocks. With Version 1.4.1 Service Refresh 2 onwards, you can use the -Xk and -Xp command-line options to specify kCluster and pCluster sizes. For example:
-Xknnnn
where nnnn specifies the maximum number of classes the kCluster contains. -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. For example:
<GC(VFY-SUM): pinned=4265(classes=3955/freeclasses=0) dosed=10388 movable=1233792 free=5658>
The pinned and classes sizes are about the right size needed for the -Xk parameter. We recommend 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; although, because each object might be a different size, it is hard to predict the requirements for the pCluster and pCluster overflow options. You can specify the pCluster and pCluster overflow sizes using the -Xp command-line option:
-Xpiiii[K][,oooo[K]]
where iiiispecifies 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. | |
| | |
| |
|
Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, Java SDK Operating system(s): AIX, Linux, Windows Software version: 3.5, 4.0, 5.0, 5.1, 6.0 Software edition: Edition Independent Reference #: 1176363 IBM Group: Software Group Modified date: 2004-09-17
(C) Copyright IBM Corporation 2000, 2004. All Rights Reserved.
|