Eliminating External Fragmentation in a NonMoving Garbage Collector for Java

1
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

2
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.

3
Internal and External Fragmentation

• Internal Memory lost due to the allocators
  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.

4
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.

5
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 dont move.
• Any block can satisfy any allocation request.

6
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.

7
Linked-List Example
Type
Field 3
Field 6
Field 1
Field 4
Field 7
Field 2
Field 5
Link
Link

• Object with 7 fields composed out of 3
• blocks of 16 bytes each.

8
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.

9
Tree Example
Data0
Data1
Data2
Data3
Array Type
Link 0..3
Data4
Length 11
Link 4..7
Data5
Depth 2
Link 8..10
Data6
Elements
Data7
Data8

• Tree representation of an array of
• 11 word elements composed out of
• 5 blocks of 16 bytes.

Data9
Data10
10
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.

11
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.

12
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.

13
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.

14
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.

15
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.

16
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.

17
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.

18
Run-Time Performance
Run-Time performance of the SPECjvm98 benchmarks
using different block sizes
19
Memory Performance
Minimum heap required for different block sizes
20
Memory Performance
Amount of memory allocated for contiguous arrays,
tree arrays, and objects for different block sizes
21
Memory Performance
Number of memory accesses performed for array
elements and object fields using different block
sizes
22
Memory Performance
Average number of memory accesses required to
access object fields and array elements for
different block sizes
23
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.

24
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