Realtime Garbage Collection in JamaicaVM

This article gives an introduction into JamaicaVM realtime Java technology.

The modern object oriented programming language Java relies on the concept of automatic garbage
collection (GC) to provide safe memory management. Garbage collection protects the user from hard to
debug programming errors and difficult to maintain programs on the one hand and provides secure
eecution of untrusted code on the other hand. C!style eplicit memory allocation and reclamation
techni"ues are a major obstacle for object oriented programming.
Most current garbage collector implementations still fail to give useful or proven realtime guarantees on
their runtime performance. #hile Java is applied to a gro$ing etent for the development of systems that
re"uire realtime guarantees% classical GC is not appli cable in these systems. The &eal!Time 'pecification
for Java avoids automatic memory management for hard realtime tas(s.
The JamaicaVM implements this specification and the scoped memory management that it provides as an
alternative to GC% but Jamai ca VM also provides realtime garbage collection (&TGC) as a simpler
alternative to the often comple assignment rules that are re"uired by the use of non heap memory. )nly
the combi nation of &TGC and the &T'J provide the full ease of development of Java for the development
of realtime code.
Garbage Collection Basics
The most $idely used algorithms for GC in Java are based on the mar( and s$eep or mar( s$eep
compact algorithms. GC $ith these algorithms is a cyclic process. *ormally% a single GC cycle has four
phases+ root scanning% mar(% s$eep% and compaction.
Root Scanning
,ll objects on the heap referenced by root variables are mar(ed. &oot variables are all variables that are
not stored in the heap itself% i.e.% variables on the runtime stac(s of all threads% $ithin processor registers%
or in global variables that are stored outside of the garbage collected heap.
Mark
-uring the mar( phase% all objects on the heap that are reachable from mar(ed objects $ill be mar(ed as
$ell. This phase continues until no ne$ objects can be
.igure /+ 'tandard GC phases
mar(ed% i.e.% until all objects that are reachable from root references are mar(ed.
Sweep
,fter the mar( phase% all allocated objects that have not been mar(ed are (no$n to be unreachable.
These objects are garbage0 their memory can be reused. Thus% during the s$eep phase% the heap is
traversed and all unmar(ed objects are added to free memory.
Compact
,fter the s$eep phase% free mem ory $ill in general be noncontiguous. This fragmenta tion of memory
ma(es small ranges of free memory unavailable for allo cations of larger objects and leads to reduced
memory use. The common solution to this problem is the use of an additional compaction phase that
moves allocated objects such that free memory forms a single contiguous range.
1n an incremental garbage collector% these four phases must be eecuted in small increments of garbage
collection $or( $hile the application continues its eecution and modifies the heap. .or the garbage
collector to be hard realtime% the amount of $or( to be done in these increments must be predictable and
the system must guarantee that the garbage collector recycles sufficient memory to satisfy all application
allocation re"uests.
Realtime Garbage Collection
The realtime garbage collector employed by JamaicaVM enables the use of automatic memory
management for realtime applications $ith tight timing constraints. This etraordinary facility is
accomplished through a special memory layout and carefull implementation. The $or( of garbage
collection is also shared amoung all application threads so as to minimi2e its impact on the overall
system.
Avoid Root Scanning Phase
-uring root scanning% all objects that are referenced by local variables or processor registers have to be
mar(ed. Mar(ing typically re"uires suspending the eamined thread% $hich leads to delays that are hard
to predict. The solution in the JamaicaVM is% instead of having a dedicated root scanning phase% the
runtime system ensures that copies of all root references are stored on the heap $henever a the garbage
collector may become active.
The compiler automatically generates code to store the root references and to remove the stored
references of roots that are deleted. The data structures that are used to store the copied references are
all reachable from a single root object. Conse"uently% all stored root references are reachable from this
single root object and the root scanning phase is reduced to mar(ing this single root object. Mar(ing the
copied root references becomes part of the garbage collector3s mar( phase. To avoid inconsistencies
$hen storing roots $hile mar(ing is going on% $rite
barrier code ensures correct
mar(ing of stored roots.
'pecific optimi2ations have been developed for JamaicaVM% such that the runtime cost is minimal.
.igure 4+ Java object built from fied!si2e bloc(s
Non!ragmenting "b#ect Model
,llocation and deallocation of objects of different si2es in a system $ith dynamic memory management
causes fragmentation. .ragmented memory is unused memory in small% non!contiguous ranges that
cannot be used to satisfy larger allocation re"uests. .ragmentation can cause severe loss of memory
utili2ation that is hard to predict. Current implementations often use compaction to fight fragmentation.
Memory compaction can remove fragmentation% but it destroys realtime guarantees due to the need to
move arbitrarily large objects. 'ince moving objects seems to inherently contradict the predictability
re"uirements of realtime systems% the compaction approach has been dropped in JamaicaVM.
1nstead% an object model based on non!movable bloc(s of a fied si2e is used. )bjects and arrays are
constructed from several bloc(s that need not be contiguous in memory. .igure 4 illustrates the structure
of a Java object that is spread over 5 bloc(s of e"ual si2e.
The surprising result is that this object model permits an efficient runtime performance+ since Java
objects tend to be small% most object accesses turn out to refer to the first bloc( of an object. )btaining
the value of these references can be performed in a single memory access. 'ince the object layout is
(no$n at compile time% the time re"uired for any object access can be determined statically% enabling
$orst!case eecution time analysis.
#ith typical large Java applications% one sees an average of about /./ memory accesses per object
access. 1n contrast% a compacting garbage collector has to use an additional indirection% so called handles%
to be able to move objects around. This additional indirection results in 4 memory accesses for every
object access.
$ncremental MarkandSweep
#ith the root scanning phase eliminated by copying of root references to the heap and the compaction
phase removed by a nonfragmenting object model based on fied si2e bloc(s% the remaining tas(s for the
garbage collector from .igure / are the Mar( and the '$eep phases sho$n in .igure 5. *o$% these phases
can be
.igure 5+ Jamaica GC phases
performed in incremental steps+ one incremental mar( step consists of mar(ing of one single bloc(% and
one incremental s$eep step consists of s$eeping one single bloc(. These steps are uniform and very
small. The $orst!case on a 6o$er6C processor is only about /78 machine instructions.
%hen to R&n the GC
The decision of $hen to run the garbage collector in a realtime system has to ensure that the runtime
spent for garbage collection is predictable and limited% $hile also guaranteeing that sufficient memory is
recycled such that all allocation re"uests can be satisfied. Current implementations typically use a
separate thread for the garbage collector. This approach% ho$ever% ma(es predictions on the overhead
and efficiency of the garbage collector% as re"uired in a realtime system% etremely hard.
JamaicaVM does not use a separate thread for garbage collection. 1nstead% the garbage collector is
activated $ithin an application thread $henever this thread allocates memory. 6erforming the garbage
collection $or( at each allocation automatically runs the garbage collector more aggressively $henever
more memory is allocated by the application. There is no garbage collection overhead during times $hen
no allocation is performed and high!priority threads $hich do not perform allocation $ill never be delayed
due to garbage collection. JamaicaVM provides tools to determine the $orst!case eecution time of the
garbage collection $or( re"uired at an allocation. The implementation ensures that the garbage collection
$or( is sufficient to reclaim memory fast enough for the application not to run out of memory.
S&mmar'
JamaicaVM3s realtime garbage collector runs in very small% incremental steps. These steps are performed
at a time $hich is predictable by the user+ $henever an object is allocated. -etermining the $orst!case
eecution time for object allocation is also possible. These features combined permit the use of garbage
collection even in realtime systems. &ealtime code that is eecuted in high priority threads is completely
unaffected by garbage collection $or(% and it is even possible to perform dynamic memory allocation in
realtime code since a $orst!case eecution time for an allocation can be determined.