Electronic Design

Real-Time Garbage Collection Speeds Embedded Java

Real-time garbage collection isn't an oxymoron. Just try spreading the cost of garbage collection over time so programming languages like Java can suit real-time applications without resorting to a constrained programming environment. Unfortunately, many designers are familiar with the more traditional Java virtual machines (JVMs) that aren't suitable for real-time applications. Luckily, JVM designers aren't taking this lying down. New embedded JVMs are handling garbage collection more efficiently.

Typical JVMs use a mark-and-sweep garbage collector (GC) that could take as much as a few seconds to recover unused memory for a large application. The process can be interrupted if memory can be locked down, but not for memory allocation. Such a delay is unacceptable in a real-time environment. The trick to using garbage collection in a real-time environment is to minimize the time necessary to perform garbage collection.

NewMonics (www.newmonics.com) uses a hybrid approach in its new PERC JVM. The company combines a copying generational GC with a conventional mark-and-sweep GC. Generational GCs have been around for a while, but not in embedded systems. They're more efficient because most dynamically allocated memory becomes garbage in a short time. A GC that can quickly recover garbage reduces the amount of memory needed to support a system, as there's less outstanding garbage and collection can be done less often. Typically, different generations are kept in separate regions. Some implementations on PCs with megabytes of memory use a large number of regions.

The company employs regions with the youngest data, which is kept in an area called the nursery. The GC copies live data to a second region in the nursery. After adjusting pointers to active data, the destination becomes the active region. Older data that repeatedly survives this process is copied to a region outside the nursery, where it's expected to live longer. Data outside the nursery that becomes garbage is recovered by a subsequent mark-and-sweep GC. It operates on one region at a time and merges regions when possible.

PERC uses heuristics and configuration parameters to pace the time that each GC runs. Therefore, applications have free memory when required, instead of having to start a GC cycle. Pacing allows the garbage collector to run even though there is free memory available.

The generational GC runs more frequently but takes very little time compared to the mark-and-sweep GC that may run every few seconds or minutes. The combination of pacing and generational GC minimizes the time needed to do garbage collection since only small regions are handled at a time. Consequently, less time is spent doing garbage collection. Differences can be dramatic. Applications that spent 70% of their time in the GC can spend less than 10%. No longer must garbage collection be a drag on real-time performance.

See associated Figure 1
See associated Figure 2

Divide free memory into multiple regions
Frequent generational GC in nursery
Mark-and-sweep over all regions
Heuristics used to anticipate GC needs
GC can be tailored for application performancerequirements

Most garbage occurs in nursery
Nursery GC is fast
High-priority tasks can always allocate
Paced GC guarantees free memory
200-ms interrupt latency

GC interrupt latency is less but is measurable
More complex GC
Maximum allocation size is limited by region size

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.