Eliminating External Fragmentation in a Non-Moving Garbage Collector for Java Author: Fridtjof Siebert, CASES 2000 Michael Sallas Object-Oriented Languages & Systems November 27, 2001

Introduction Fragmentation is a serious problem in dynamic memory management. Most Java garbage collection algorithms are not adequate to handle fragmentation in real-time systems. A non-moving garbage collection algorithm eliminates fragmentation.

Internal and External Fragmentation Internal: “Memory lost due to the allocator’s policy of object alignment and padding.” External: “Memory lost because free memory is non-contiguous in a way that an allocation request cannot be satisfied even though the total amount of free memory would be sufficient for the request.”

Moving Collectors Moves memory in a way that free memory is contiguous. Compacting mark & sweep collector used in the Sun JDK. All references to an object that has moved must be updated. This can be avoided with forwarding pointers.

Fixed Size Blocks Heap is divided into a set of equal size blocks. Allocations are satisfied with a set of possibly non-contiguous blocks. Blocks don’t move. Any block can satisfy any allocation request.

Building Objects Out of Blocks A linked-list of blocks is used to represent Java objects. Typical Java object is between 12 and 23 bytes. One word per block is reserved for the link.

Linked-List Example Field 2 Link Type Field 1 Field 5 Link Field 3 Field 4 Field 6 Field 7  Object with 7 fields composed out of 3 blocks of 16 bytes each.

Building Arrays Out Of Blocks A linked-list would impose a very high cost on array accesses. A tree can be used to represent arrays. Depth of tree is stored in the array. Array data is stored in the leaf nodes only.

Tree Example Depth: 2 Elements Array Type Length: 11 Link Link 0..3 Link 4..7 Data[2] Data[3] Data[0] Data[1] Data[6] Data[7] Data[4] Data[5] Data[10] Data[8] Data[9]  Tree representation of an array of 11 word elements composed out of 5 blocks of 16 bytes.

Optimizing Arrays Use linear representation for arrays whenever possible. Can be used whenever a sufficiently large contiguous range of free blocks is available and can be found quickly enough. Try for linear representation, if not available, use tree representation.

Moving Collectors & References If an object is moved, all references to it must be updated. All reference variables must be known and modifiable by the collector. Handles can be used to avoid changing all references to an object. Incurs significant run-time overhead. Objects still might be accessed directly by compiled code.

Non-Moving Collectors & References Objects are never moved. Collector does not have to update references. Collector only needs to find 1 reference to an object. Handles are not needed. Compiler may use direct references to objects without informing the garbage collector.

Moving Large Objects Moving collector must move objects atomically. This could create a long pause that is unacceptable for real-time systems. Incremental moving would impose an unacceptable run-time overhead. Non-moving collector never moves objects so this is not a problem.

Scanning Large Objects Moving collectors will typically atomically scan an object for references during the mark phase. This could create a long pause that is unacceptable for real-time systems. Non-moving collectors scan blocks for references. All blocks are same size, so there is an constant worst-case upper bound.

The Jamaica Virtual Machine Implementation of a JVM and static compiler that use fixed-size blocks. Arrays are allocated in the contiguous representation if possible. The first free range in the free list and the largest free range found during the last garbage collection cycle are checked. If a large enough chunk of memory is not found then the tree representation is used.

The Jamaica Virtual Machine Garbage Collection Algorithm Does not know about Java objects. Works on fixed-size blocks. Simple mark and sweep collector Reference-bit-vector is used to indicate if each word on the heap is a reference. Activated whenever an allocation is performed.

Block Size Different applications will perform best with different block sizes. Jamaica VM Block size is configurable between 16 and 128 bytes. Optimal general block size is 32 bytes.

Run-Time Performance Run-Time performance of the SPECjvm98 benchmarks using different block sizes

Memory Performance Minimum heap required for different block sizes

Memory Performance Amount of memory allocated for contiguous arrays, tree arrays, and objects for different block sizes

Memory Performance Number of memory accesses performed for array elements and object fields using different block sizes

Memory Performance Average number of memory accesses required to access object fields and array elements for different block sizes

Conclusion A new object model using fixed-size blocks to avoid fragmentation has been presented. This model gives hard real-time guarantees concerning fragmentation that traditional garbage collectors cannot. Applications that do not require hard real-time behavior can benefit.

References Fridtjof Siebert: Eliminating External Fragmentation in a Non-Moving Garbage Collector For Java, Compilers, Architectures and Synthesis for Embedded Systems (CASES), San Jose, December 1999 Fridtjof Siebert: Hard Real-Time Garbage Collection in the Jamaica Virtual Machine, Real-Time Computing Systems and Applications (RTCSA ’99), Hong Kong, December 1999