Garbage Collector (GC) component of the VM reclaims memory used by objects that are no longer in use by the Java application. There are a wide variety of algorithms used to implement garbage collectors, that trade off various attributes like application throughput, heap size, foot print, memory fragmentation, allocation time, application pause times (the period during which threads are halted for GC operations), etc. The standard GC included with the Apogee JREs has been carefully designed and implemented to make the above trade offs that result in a GC that is suited to a large range of embedded systems; it includes the logic to dynamically adjust its configuration for the best performance based on the behavior of the application that is running.  Although high performance, standard GC does not possess properties required for execution of real-time Java applications; in such situations, our Real-time GC (RTGC) is available.

The standard GC is based on generational design, which exploits the behavior of Java applications where a large percentage of objects created by the application are short lived or temporary. The generational GC divides the object heap into two spaces (or generations), a new space and an old space. A new space is further divided into 2 equal spaces. Objects are allocated from one of the new spaces until an allocation failure occurs and scavenger cycle is triggered. In a scavenger cycle, only "used" objects are copied from one new space into another new space; some objects, which have been copied a number of times are promoted (moved) to old space. Since the new space is only a fraction of the entire heap, the scavenger cycle cause only a brief pause for the application. As objects are moved to the old space, it may become full and require a global collection (using mark-and-sweep) to free objects that have become dead. Since the old space is larger, global collection requires more time, but its less frequently to occur.

GC also provides for a high degree of configuration and tuning, allowing for target-specific optimizations
  • ability to control initial and maximum amount of memory
  • ability to control when GC is run
  • ability to optimize for performance or latency
  • ability to trace/debug GC execution
GC behavior is controlled via number of command line options, which also include:
 Option  Description
 -Xmn<x>  set initial/maximum new space size to <x> (e.g. 1024k or 1M)
 -Xmns<x>  set initial new space size to <x>
 -Xmnx<x>  set maximum new space size to <x>
 -Xmo<x>  set initial/maximum old space size to <x>
 -Xmos<x>  set initial old space size to <x>
 -Xmox<x>  set maximum old space size to <x>
 -Xmoi<x>  set old space increment to <x>
 -Xms<x>  set initial memory size to <x>
 -Xnoclassgc  disable dynamic class unloading
 -Xclassgc  enable dynamic class unloading
 -Xalwaysclassgc  enable dynamic class unloading on every GC
 -verbose:gc  write summary of GC operations to stdout
 -verbose:sizes  write sizes of each memory space to stdout