Scheduling of hard real-time garbage collection

Abstract

Automatic memory management or garbage collection greatly simplifies development of large systems. However, garbage collection is usually not used in real-time systems due to the unpredictable temporal behavior of current implementations of a garbage collector. In this paper we propose a real-time garbage collector that can be scheduled like a normal real-time thread with a deadline monotonic assigned priority. We provide an upper bound for the collector period so that the application threads will never run out of memory. Furthermore, we show that the restricted execution model of the Safety Critical Java standard simplifies root scanning and reduces copying of static data. Our proposal has been implemented and evaluated in the context of the Java processor JOP.

Scheduling real-time garbage collection on uniprocessors

“…It is easy to see that the condition is necessary for the system not to run out of memory as objects that become unreachable during the GC cycle in which they are allocated (they are called floating garbage) can only be freed by the end of the subsequent GC cycle. Previous work has shown that this is a sufficient condition [Robertz and Henriksson 2003;Schoeberl 2010]. The intuition behind the proofs is as follows.…”

“…RELATED WORK Henriksson [1998] derived an initial schedulability analysis for a slack mostly-concurrent two-space copying GC, which he then extended [Robertz and Henriksson 2003]. The core of the extended analysis applies, as shown in Schoeberl [2010], to any slack based single-heap GC, and thus we also use it in this paper. In this analysis, the GC is scheduled as a periodic task with lower priority than all other hard real-time tasks.…”

Non-blocking garbage collection for real-time Android

“…In situations where GC has to coexist with mutators that must meet specific deadlines, four points have been identified by Schoeberl that have to be considered with respect to predictability of time overhead [21]:…”

“…• Non-cascading deallocation [23] • Deutsch-Bobrow method [5] • Slack-based scheduling [9] • Delegated local root set scanning [21] • Cycle detection [3] These mechanisms ensure that the presented reference counting collector can run incrementally, concurrently and with minimal interference to the execution of mutators within the same instance of the DVM.…”

“…Further, local root sets of active mutators have to be scanned and it is necessary to suspend all mutators for the duration of the scan. By applying the concept of delegated local root set scanning [21], a mutator is only suspended if it does not run with real-time priority. If the mutator is a real-time thread, only a flag for this thread is set, signaling the thread to scan its local root set when enough time is available for this task.…”