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.
Realtime GC behavior is controlled via -Xrtgc:opt[,opt] directive, where available options include: 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
|