Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

The garbage collectors for the Jikes RVM are provided by MMTk. The MMTk: The Memory Manager Toolkit describes MMTk and gives a tutorial on how to use and edit it and is the best place to start.

The RVM can be configured to employ various different allocation managers taken from the MMTk memory management toolkit. Managers divide the available space up as they see fit. However, they normally subdivide the available address range to provide:

  • a metadata area which enables the manager to track the status of allocated and unallocated storage in the rest of the heap.
  • an immortal data area used to service allocations of objects which are expected to persist across the whole lifetime of the RVM runtime.
  • a large object space used to service allocations of objects which are larger than some specified size (e.g. a virtual memory page) – the large object space may employ a different allocation and reclamation strategy to that used for other objects.
  • a small object allocation area which may be divided into e.g.two semispaces, a nursey space and a mature space, a set of generations, a non-relocatable buddy hierarchy etc depending upon the allocation and reclamation strategy employed by the memory manager.

Virtual memory pages are lazily mapped into the RVM's memory image as they are needed.

The main class which is used to interface to the memory manager is called Plan. Each flavor of the manager is implemented by substituting a different implementation of this class. Most plans inherit from class StopTheWorldGC which ensures that all active mutator threads (i.e. ones which do not perform the job of reclaiming storage) are suspended before reclamation is commenced. If the RVM scheduler is configured to run with N virtual processors (see Thread Management) capable of running N concurrent mutator threads then a StopTheWorldGC collection will be performed by N collector threads, each one running on its own virtual processor.

Generational collectors employ a plan which inherits from class Generational Inter alia, this class ensures that a write barrier is employed so that updates from old to new spaces are detected.

The RVM does not currently support concurrent garbage collection.

The Jikes RVM may also use the GCSpy visualization framework. GCSpy allows developers to observe the behavior of the heap and related data structures.

  • No labels