Real-time Java, part 4th

Real-time systems and garbage collection

The difference between real-time (RT) application development and common application development is that the former imposes time constraints on partial run-time behavior. Such restrictions are usually implemented for certain parts of the application, such as interrupt handlers, whose code to respond to interrupts must complete the work within a given time span. For hard RT systems, such as heart monitors or defense systems, it can be seen as a catastrophic failure of the entire system if such systems run out of time. For a soft RT system, exceeding the time limit can have some adverse effects--such as the GUI not displaying all the results of its monitoring stream--but it does not cause the system to fail.

In Java applications, the Java Virtual Machine (JVM) is responsible for optimizing run-time behavior, managing the object heap, and engaging the operating system and hardware. Although this management layer between language and platform simplifies software development, it also brings a certain amount of overhead to the program. GC is an example of this, which usually causes the uncertainty in the application to pause. The frequency and length of pauses are unpredictable, making the Java language traditionally unsuitable for developing RT applications. Some existing solutions based on the Java real-time specification (RTSJ) enable developers to avoid the uncertainties of Java technology, but need to make changes to existing programming models.

Metronome is a deterministic garbage collector that provides restricted low pause times and specified application utilization for standard Java applications. The reduction in the limited pause time stems from increased collection methods and meticulous engineering decisions, including basic changes to the VM. Utilization is the percentage of time in a particular time window that an application can run, and the remaining time is used for GC. Metronome enables users to specify the level of utilization for an application. Combined with RTSJ, metronome enables developers to build software with a defined low pause time and no pause for a small time window. This article explains the traditional GC limitations of RT applications, details the metronome approach, and provides some tools and guidance for developing a hard RT application using Metronome.

Traditional GC

Traditional GC implementations use the Stop-the-world (STW) method to recover heap memory. The application runs until the heap is depleted of available memory, at which point the GC stops all application code, performs garbage collection, and then lets the application run.

Figure 1 illustrates the traditional STW pauses for GC activity, which are often unpredictable in terms of frequency and duration. The traditional GC is indeterminate because the amount of work required to recover the memory depends on the total number and size of objects used by the application, the connections between those objects, and how much work is required to free up enough heap memory to meet future allocations.

Figure 1. Traditional GC Pause