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 does not support applications with deterministic timing requirements (i.e. the real-time applications), since it has an unbounded worst case application pause time, which may cause an application to miss deadlines.

The Real-time Garbage Collector (Real-time GC) has been designed by Apogee to provide a hard time limit on all of its activities.  This is accomplished by utilizing an incremental mark/sweep collector, which performs its collection in a small periodic intervals and reserves a percentage of the CPU for the application during each period.  The period and percentage reserved for the application use (utilization) can be configured by the developer to minimize the impact of GC, while maximizing application performance.  For example, a period of 5ms and a utilization of 80% would bound the worst case pause time to 1ms out of every 5ms.  Java applications must be carefully designed to have a bounded allocation rate and heap size in order for the collector to keep up.

Real-time GC also provides for a high degree of configuration and tuning, such as
  • ability to control amount of memory
  • ability to control period and utilization
  • ability to control thread priority for GC thread
  • ability to trace/debug Realtime GC execution
Realtime GC behavior is controlled via -Xrtgc:opt[,opt] directive, where available options include: 

 Option  Description
 sets priority of the GC thread (1-38).  Specifying priority=0 will set GC thread priority lower then any user thread.  Specifying priority=255 (default) will set GC thread priority higher then any JRE created thread.
 number of microseconds for the period.  Valid range is from 1 to 10,000,000, with the default value of 20,000.  For operating systems with a system tick based scheduler, the period should be a multiple of the system tick period.
 percentage reserved for the application use.  Valid range is from 5 to 95, with the default value of 70.
 -verbose:gc  write statistical information to stdout