offline gc
TRANSCRIPT
Offline GC: Trashing Reachable Objects on Tiny Devices
Faisal AslamLUMS & University of FreiburgDHA, Lahore 54792, Pakistan
Luminous FennellUniversity of Freiburg
Freiburg 79110, Germany
Christian SchindelhauerUniversity of Freiburg
Freiburg 79110, Germany
Peter ThiemannUniversity of Freiburg
Freiburg 79110, Germany
Zartash Afzal UzmiLUMS SSE
DHA, Lahore 54792, Pakistan
AbstractThe ability of tiny embedded devices to run large and
feature-rich Java programs is typically constrained by theamount of memory installed on those devices. Furthermore,the useful operation of such devices in a wireless sensorapplication is limited by their battery life. We propose agarbage collection (GC) scheme called Offline GC which al-leviates both these limitations. Our approach defies the cur-rent practice in which an object may be deallocated only ifit is unreachable. Offline GC allows freeing an object that isstill reachable but is guaranteed not to be used again in theprogram. Furthermore, it may deallocate an object inside afunction, a loop or a block where it is last used, even if thatobject is assigned to a global field. This leads to a largeramount of memory available to a program.
Based on an inter-procedural and field-sensitive data flowanalysis we identify, during program compilation, the pointat which an object can safely be deallocated at runtime. Wehave designed three algorithms for the purpose of makingthese offline deallocation decisions. Our implementation ofOffline GC indicates a significant reduction in the amount ofRAM and the number of CPU cycles needed to run a varietyof benchmark programs. Offline GC is shown to increase theaverage amount of RAM available to a program by up to 82%compared to a typical online garbage collector. Furthermore,the number of CPU cycles consumed in freeing the memoryis reduced by up to 94% when Offline GC is used.
Categories and Subject DescriptorsD.3.4 [Programming Languages]: Processors—Mem-
ory management (Garbage Collection)
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. To copy otherwise, to republish, to post on servers or to redistributeto lists, requires prior specific permission and/or a fee.SenSys’11, November 1–4, 2011, Seattle, WA, USA.Copyright 2011 ACM 978-1-4503-0718-5/11/11 ...$10.00
General TermsAlgorithms, Design, Experimentation, Performance
KeywordsGrabage Collection, Sensor Networks, Offline Memory
Management, JVM, Java Virtual Machine, TakaTuka
1 IntroductionA typical wireless sensor mote has limited amount of
hardware resources: the RAM is around 10 KB or less, theflash is usually limited to 128 KB and a 16-bit or an 8-bitprocessor is used [1]. Despite their limited resources, sev-eral motes may form a network to realize many useful andpowerful applications. Such applications include environ-ment monitoring, military surveillance, forest fire monitor-ing, industrial control, intelligent agriculture and robotic ex-ploration. The motes were traditionally programmed usinglow-level languages but recent advances in Java Virtual Ma-chine (JVM) design enable programming these motes usingthe Java language [2, 3, 4]. The capability to program themotes in a high level language not only expands the devel-oper base but also allows rapid application development.
Garbage collection is one of the features that makesJava particularly attractive for application development onmemory-constrained motes. The basic principle of a garbagecollection algorithm is to find the data objects that are nolonger reachable during program execution and reclaim thememory used by such objects. To this end, a garbage collec-tion algorithm traverses through the object graph starting atthe root set, the set of objects always reachable from the pro-gram. All objects that are not visited during the object graphtraversal are declared unreachable and hence can be freed.All existing garbage collection algorithms work on this basicprinciple, although the exact algorithmic details vary acrossdifferent implementations [5]. This approach is online as theobjects that can be deallocated are identified during the ex-ecution of the program. The online garbage collection hastwo main drawbacks, specifically for resource constraineddevices such as wireless sensor motes:
• An online garbage collector cannot deallocate an ob-ject that is reachable from the root-set, even though theobject may never be used again in the program. This
leads to a reduced amount of RAM that can otherwisebe available to the program.
• The online garbage collector is frequently called duringthe program execution, each time traversing the objectgraph, even if only a small number of objects can befreed. This consumes excessive CPU cycles resultingin a reduced battery lifetime.
In contrast with the online garbage collection, offlineschemes can make deallocation decisions during the com-pilation of the program [6, 7, 8, 9, 10]. However, theseschemes do not typically aim to deallocate an object thatis still reachable from the root-set or is part of the root-set.These schemes reduce the CPU cycles consumption of a pro-gram without making additional RAM available to the pro-gram. This paper presents a new offline scheme, called Off-line GC. The distinguishing feature of Offline GC is that itallows freeing objects that are still reachable. Thus, OfflineGC offers two major benefits when building applications forresource constrained devices: (i) A larger free memory poolbecomes available to a program during runtime, allowing de-ployment of bigger programs with an extensive functionality.(ii) The search for unreachable objects by traversing the ob-ject tree as in traditional online garbage collectors, can beperformed less frequently saving on CPU cycles and the bat-tery life. Note that Offline GC does not completely eliminatethe need of using traditional online garbage collector; how-ever the latter is invoked much less frequently. It is becauseno offline scheme can always predict, during a program com-pilation, the usage and reachability of all the objects to becreated during the execution of that program.
Offline GC works in three phases, the first two occur dur-ing program compilation and the third during the programexecution: (1) Data-flow analysis phase during which theJava bytecode is analyzed and necessary program informa-tion is collected. For this purpose, we employ a componentcalled Offline GC Data-Flow Analyzer (OGC-DFA). (2) Inthe second phase, deallocation decisions are made based onthe data collected in the first phase, and the bytecode is ac-cordingly updated. We refer to it as the bytecode updatingphase and the component of Offline GC which implementsthis phase is referred to as Offline Garbage Identifier (OGI).(3) The third phase, the Runtime Deallocation phase, is theone in which the objects that are no longer needed (and iden-tified as such after the first two phases) are actually deallo-cated. For this purpose, the information included in the Javabytecode during the bytecode updating phase is utilized. Al-together, this paper makes the following contributions:
1. Design and implementation of an inter-procedural,field-sensitive, flow-sensitive, and context-sensitivedata flow analyzer.
2. Design and development of three algorithms to makeoffline deallocation decisions by identifying the byte-code points where objects, that may still be reachable,can be safely deallocated.
3. Introduction of two new bytecode instructions to en-force offline deallocation decisions and developingJVM support for executing these bytecode instructions.
4. A thorough evaluation of Offline GC for a variety ofbenchmarks on real world platforms (sensor motes).
2 Motivating ExampleWe first present an example, in Fig. 1 that motivates the
use of Offline GC. Although Offline GC operates on byte-code, this example uses the source code for better read-ability. Furthermore, this example shows a single functionfor the sake of simplicity even though Offline GC is inter-procedural. The function foo of the example uses three ob-jects: (1) An object inObj that is received as a parameter andis used in many other functions of the program. Offline GCwill free inObj inside foo if this is the last function where itis used. (2) An object localObj that is created inside a whileloop. This object will be deallocated immediately after itslast use inside the same loop, given that each loop iterationwill overwrite the local variable. (3) An object globalObjthat is stored in a global field that can be used by many otherfunctions. This object is also deallocated after its last use, ifthat happens to be within the foo function.
All three objects are deallocated by Offline GC when theyare still reachable and cannot be deallocated by a typical on-line GC. Furthermore, these object are deallocated inside thesame function, loop or code block they are used in. Ourscheme can track individual objects. That is multiple ob-jects allocated at the same site can be deallocated at differentpoints of execution. For example, an object contained withinlocalObj always has the same allocation site but could befreed at two different points of execution, as indicated in theif-else block within the while loop.
1 p u b l i c vo id foo ( I n p u t inObj ) {2 b a r ( inObj ) ;3 i f ( . . . ) {4 i nObj . c a l l ( ) ;5 / / OFFLINE GC FREE f o r inObj6 }7 whi le ( . . . ) {8 Loca lObj l o c a l O b j = new Loca lObj ( ) ;9 l o c a l O b j . f o o b a r ( g l o b a l O b j ) ;
10 i f ( . . . ) {11 l o c a l O b j . i ++;12 / / OFFLINE GC FREE f o r l o c a l O b j13 } e l s e {14 l o c a l O b j . j ++;15 / / OFFLINE GC FREE f o r l o c a l O b j16 }17 }18 g l o b a l O b j . k = 5 ;19 / / OFFLINE GC FREE f o r g l o b a l O b j20 }
Figure 1. Demonstrating the use of Offline GC for theDeallocation of reachable objects.
3 Offline GC Data-Flow AnalyzerOffline GC data-flow analyzer (OGC-DFA) is built upon
an existing data-flow analyzer (BV-DFA) used for Java byte-code verification (§4.9.2 of [11]). The OGC-DFA and BV-DFA work in similar ways. That is, they both are flow-
sensitive, path-insensitive and operate on object types ratherthan real objects. However, they differ in some importantaspects. First, our OGC-DFA is interprocedural context-sensitive as well as field-sensitive. Second, unlike BV-DFA,the OGC-DFA creates a new object type only when encoun-tering an instruction that would actually create an object atruntime. Third, the OGC-DFA differentiates between thereference types created by two different instructions, evenwhen both of these reference types are the same. The OGC-DFA maintains this differentiation by assigning a unique tagto the reference type based on the instruction which createdthat reference type. Owing to these differences, the OGC-DFA is able to conduct a more precise analysis as comparedto the BV-DFA.
We first provide a review of the Java bytecode verifica-tion data-flow analyzer (BV-DFA) on which the OGC-DFAis based. This is followed by a description of the enhance-ments made by the Offline GC data-flow analyzer (OGC-DFA) in the subsequent section.
3.1 BV-DFA: Implementation ReviewThe existing Java bytecode verification mechanism ana-
lyzes and verifies the bytecode for each function in a givenprogram. In this process, each function is analyzed exactlyonce in an arbitrary order with no relation to the order ofexecution [11]. Each function has an indexed list of byte-code instructions. For a function being analyzed, the BV-DFA maintains the following data structures:
• A change-bit for each bytecode instruction. If this bitis set, it indicates that the instruction needs to be exam-ined. These bits change state during the analysis pro-cedure and the function analysis is terminated when allthese bits become unset.
• An entry-frame for each bytecode instruction. Thisframe consists of two structures, each of which containsthe “types” of data values rather than the actual values.The first is a list of (types of) local variables (referredto as LocVar) and the second is a stack containing typesof instruction operands (referred to as OpStk).
• A temp-frame which is meant to temporarily hold thedata from an entry-frame. There is only one temp-frameneeded during the verification of the entire function.
When a function is picked by BV-DFA for verification analy-sis, the first bytecode instruction has the following status: thechange-bit is set, the OpStk is empty, and LocVar only con-tains the types of the input parameter to the function. For allthe remaining bytecode instructions, the change-bit is unsetand OpStk and LocVar are empty. The working of BV-DFAfrom the Java specifications is summarized as:
1. Select any instruction whose change-bit is set, and unsetthe change-bit. If no instruction is found whose change-bit is set then the data-flow analysis for the current func-tion terminates.
2. Copy the entry-frame of the selected instruction intothe temp-frame. Execute the selected instruction andupdate the temp-frame based on its result. Note thatan instruction execution is based on data types ratherthan actual values. For example, execution of ILOAD 1
pushes the data type integer from LocVar (at index 1)on to the OpStk, rather than pushing an actual integervalue.
3. Determine the set of all possible candidate instructionsthat may follow the current instruction in the controlflow graph of the function [11]. Clearly, there is onlyone instruction from the candidate set which followsthe current instruction during program execution withactual data. However, it is not always possible to as-certain which of the instructions from the candidate setwill follow the current instruction just by looking at thetypes during the data-flow analysis. Hence, in the pro-cess of data-flow analysis, all possible instructions thatmay follow next are included in the candidate set.
4. Using the information in the temp-frame, update theOpStk and LocVar of the entry-frame for each instruc-tion in the candidate set of the next instructions.
• If a candidate instruction has been never analyzedbefore, then copy the temp-frame into the entry-frame of the next instruction and set its change-bit.
• If a candidate instruction has been analyzed be-fore, then “merge” the temp-frame into the entry-frame of that instruction. In this case, the change-bit is set only if the “merge” process changes anyelement in the OpStk or LocVar of the entry-frameof the candidate instruction.
5. Continue at step 1.To explain the merge process, we first note that for a valid
Java binary, the control flow graph ensures that the prim-itive data types1 at corresponding locations in temp-frameand entry-frame are identical. This holds true for primitivetype elements in OpStk as well as in LocVar. However, thereference types at the corresponding locations (elements ofOpStk or LocVar) of temp-frame and entry-frame may differ.If these two reference types are identical, the merge processtakes no action. Otherwise, it works as follows:
1. For OpStk: The least common superclass of the two ref-erence types is determined and the element of the OpStkin the entry-frame is updated with its type.
2. For LocVar: The corresponding element of the LocVarin entry-frame is set as empty (or unused).
3.2 Offline GC DFAThe Offline GC Data-flow Analyzer (OGC-DFA) builds
upon the BV-DFA, also working with data types rather thanwith actual values, albeit with some important differences.To highlight these differences, we first note that the goal ofBV-DFA is bytecode verification, but OGC-DFA must col-lect information that can be used to free the actual objectsduring program execution. The BV-DFA treats the types lib-erally which is acceptable for the purpose of bytecode veri-fication but not for reclaiming the allocated memory. For an
1The primitive data types include byte, short, char, boolean, int,long, float and double. Note that BV-DFA considers byte, short,char and boolean as int data type and does not differentiate betweenthem.
understanding of the working of OGC-DFA, we enlist mech-anisms where it differs from BV-DFA in the following.
3.2.1 Precision in Generation of Reference Types
When the BV-DFA encounters a reference type for inclu-sion in the OpStk or LocVar of the temp-frame, this referencetype may refer to any super class of the actual data object thatwould be encountered during runtime. In contrast, the OGC-DFA must know the exact reference type during data-flowanalysis that would be encountered during runtime. To ob-tain the precise type information in OGC-DFA, we note thatnew objects can be created at runtime using only the follow-ing five bytecode instructions [11]:
NEW, NEWARRAY, ANEWARRAY, LDC and MULTANEWARRAY
Both BV-DFA and OGC-DFA create new reference typeswhen any of these bytecode instructions are analyzed. In ad-dition to this, the BV-DFA may create a new reference typeswhile (i) analyzing the bytecode instructions that either in-voke a function or retrieve data from a field, or (ii) mergingthe temp-frame into the entry-frame. The OGC-DFA doesnot create new reference types in these additional cases.
3.2.2 Reference Type Tagging
Rather than tracking individual objects, the OGC-DFAtracks a group of objects created by an instruction at a spe-cific location within the bytecode. This grouping is moreprecise compared to the type-based grouping of objects inBV-DFA.
To identify a group of objects, the OGC-DFA assigns atag to the reference type created by an instruction at index iin function f . The tracking is then based on the assigned tagwhich ensures that each object in a group has been createdby an instruction at a specific location within the bytecode.That is, each reference type created by an instruction at indexi in the instruction list of function f will always be assignedthe same tag, no matter how many times that instruction isanalyzed. Furthermore, this tag will be different from the tagassigned to a reference type created by any other instruction,even if that instruction creates the same reference type.
The OGC-DFA, therefore, works with tags consideringthe reference type information as implicit. Thus, we will usethe term “tag” in place of “tagged reference type” for thediscussion that follows.
3.2.3 Frame Merging
The OGC-DFA needs to maintain precise type informa-tion so that the OGI can subsequently make correct deallo-cation decisions. Since the merge process in BV-DFA losesthe precise type information, as described in Section 3.1, theOGC-DFA uses the following enhancements to the mergeprocess: it allows each element in the OpStk to maintain aset of tags. Furthermore, an element of the OpStk of thetemp-frame is merged into the corresponding element of theentry-frame by taking a union of their respective sets of tags.This enhancement has two implications. First, elements ofLocVar are also permitted to maintain a set of tags. Second,the execution of some instructions during the data-flow anal-ysis phase is modified as they need to operate on a set of tagsinstead of a single reference type per element.
3.2.4 Storing Reference Types in FieldsIn Java there are two kinds of fields: static and non-
static. The OGC-DFA uses field data structures, one perclass for static fields and one per tag for non-static fields.This is different from the BV-DFA which does not use anysuch structure. The consequence is that the OGC-DFA cancollect precise type information from fields while the BV-DFA is unable to do so. Collection of this precise informa-tion is actually necessary for OGC-DFA to identify the cor-rect type of an object a bytecode instruction may load fromthe field. Maintaining the field information has implicationson the data-flow analysis: each bytecode instruction that re-ceives data from a field must have its change-bit set when-ever that field is updated. This is necessary because the orderof execution can not be determined at compile time. For thissame reason, a tag stored in a field data structure should notbe overwritten. Thus, a field data structure contains a list oftags, each indicating a possible reference type that the fieldmay hold during program execution. The OGC-DFA handlesthe arrays in a similar way; however, the index to the arrayelements is ignored.
3.2.5 Interprocedural AnalysisBesides collecting the precise type information through
the use of tags, the OGC-DFA also tracks which set of byte-code instructions will use a specific tag during program ex-ecution. That is, it tracks the tags passed to a function,returned from a function, and used by various instructionswithin that function. Therefore, the OGC-DFA performs theanalysis in an interprocedural context-sensitive manner; italways starts from the main function of the application.When the OGC-DFA encounters an invoke instruction withina function being analyzed, it halts the analysis of the currentfunction while continuing with the newly invoked functionuntil its analysis is completed.2 The invoked function mayhave multiple bytecode instruction branches, each returningits own set of tags to the parent function. All such tags aremerged and provided to the parent function whose analysiscontinues from where it was left.Scalability: A consequence of the interprocedural nature ofanalysis carried out by the OGC-DFA is that a function maybe up for analysis multiple times if invoked from multiplelocations in the bytecode. To speed up the analysis for largeprograms, the OGC-DFA “caches” the analysis results (theset of return tags) for a function invoked with given param-eters. Before starting to analyze a function, the cache ischecked. In case of a cache hit (a previous analysis of thesame function with same parameters), re-analysis of the in-voked function is avoided.
3.2.6 ThreadsThe OGC-DFA analyzes all the threads independently
one after the other, except in the case when there is an updatein the data structure for a field that is shared among multiplethreads. In such a case, the OGC-DFA identifies all the byte-code instructions that may retrieve data from that field, in allfunctions of all threads analyzed previously. Then, it sets the
2A function is invoked after following the proper functionlookup procedures as described in Chapter 6 of the JVM specifi-cations [11].
change-bit for those instructions and partially re-analyzes allthe previously analyzed affected threads. This is to ensurethat each instruction considers a superset of tags whose cor-responding reference types may be used by the instructionat runtime, without making any assumption about threadscontext-switching.
4 Offline Garbage IdentifierThe offline Garbage identifier (OGI) works during com-
pilation of a program in the second phase of Offline GC.This component is responsible for (i) making deallocationdecisions using three graph algorithms, and (ii) updating thebytecode so that these deallocation decisions can be carriedout at runtime. The bytecode is updated by inserting the fol-lowing two customized instructions:
• OFFLINE GC NEW <TAG>: This instruction ismeant to assign the given tag to a newly created objectat runtime. Thus, the OGI inserts this immediately aftereach bytecode instruction which creates a new object.
• OFFLINE GC FREE <TAG>: This instruction ismeant to deallocate all the objects which were previ-ously assigned the given tag during program execution.Thus, the OGI inserts this immediately after the in-structions where it is safe to deallocate all the objectsgrouped by the given tag. Such points of insertions aredetermined based on the offline deallocation decisions.
We have designed three graph algorithms for making off-line allocation decisions. These algorithms determine the in-sertion points within the bytecode for the OFFLINE GC FREE
instructions. Each of these algorithms is used independentlyand is suited for different code scenarios. Our implementa-tion uses all the three algorithms to ensure that a variety ofprograms can benefit from the offline deallocation decisions.We use the following terminology to describe the working ofthese algorithms.Function-Call: This is simply the invocation of a givenfunction with a given set of input tags.Instruction-Graph of a function: This is a directed graphin which each node represents a bytecode instruction in thatfunction. These nodes are connected through links whichcollectively chalk out every possible execution path onlythrough that function, ignoring invocation of any other func-tion. Each node in the Instruction-Graph of a function con-tains the set of all tags that may be used by the correspondinginstruction, for a given Function-Call.Instruction-Graph of a thread: The instruction graph of athread chalks out every possible execution path through theentire program thread, in a path insensitive manner. Thus,this is quite similar to the Instruction-Graph of a functionexcept that the control flow (i) starts at the entry function ofthe thread, and (ii) may now follow the function invocations.Function-Call-Graph of a thread: This is a directed graphin which each node represents a Function-Call. Therefore,this graph provides all possible flows in the thread at thegranularity level of a function.DAG of an Instruction-Graph: The DAG of an Instruction-Graph is obtained by substituting each strongly connectedcomponent in the Instruction-Graph with a single node. Such
a composite node of the DAG contains all the tags of all thenodes of the underlying strongly connected component.
4.1 Algorithm 1: PNR (Point of No Return)This algorithm is designed to find points of no return
(PNR) of a tag. A PNR of a tag refers to a bytecode in-struction; it is guaranteed that the given tag is not used eitherat this instruction on any subsequent instruction during theexecution of the program. Such an instruction is referred toas the point of no return (PNR) of that tag. All the objectsassigned with this tag at runtime can safely be deallocatedat this point of execution. Thus, the OFFLINE GC FREE in-struction for a tag can be inserted immediately before a PNRof that tag. The PNR algorithm operates on the DAG of theInstruction-Graph of a program thread as shown in the asso-ciated pseudocode.
Algorithm 1 Point of No Return (PNR)
1: Consider the DAG G = (V,E) of the Instruction-Graph2: Compute a topological ordering v1, . . . ,v|V | of the nodes
of G starting starting with the sinks3: for i← 1 to |V | do4: BMvi
← set of all tags used in vi joint with the setsBMw of all successors w of vi (stored as bitmap)
5: end for6: for i← 1 to |V | do7: for each predecessor p of vi in G do8: for each tag t of BMp do9: if t 6∈ BMvi
then10: Mark vi as the PNR of t11: Add OFFLINE GC FREE instruction for
tag t at it’s PNR12: end if13: end for14: end for15: end for
Moving the PNR: Consider the situation when multiplebytecode instructions can invoke a function. If it is deter-mined that a tag can safely be freed within the function onany such invocation, the algorithm places the PNR of thattag after the last invocation of that function. As a result,the OFFLINE GC FREE instruction is never inserted within thebytecode of a function that is invoked from multiple instruc-tions. This avoids an inadvertent deallocation of an objectduring an earlier invocation of that function than the one dur-ing which the object can be safely deallocated. It is importantto note that the algorithm can place a PNR within the byte-code of a function that is invoked multiple times from thesame bytecode instruction, such as in a loop.
4.1.1 Strengths and LimitationsThe strength of the PNR algorithm is that it can find
PNRs for tags that represent either the field objects or thelocal variables. However, the usefulness of this algorithmis diminished for programs that do not have exit points.This is because the PNR algorithm works on DAG of theInstruction-Graph of a program thread and does not have vis-ibility inside the composite nodes of the DAG.
4.1.2 ScalabilityIn addition to using the PNR algorithm for applications
developed for tiny wireless sensor motes, we also aim at us-ing this algorithm for large programs developed for power-ful computers. However, the Instruction-Graph of a programthread could be exponentially large, making the PNR algo-rithm impractical for some large programs. This is becausemultiple invocations of a function from different bytecodeinstructions will create multiple subgraphs, each represent-ing the same function in the Instruction-Graph of the thread.To maintain scalability, we use the following solution: If afunction is invoked from more than n separate bytecode in-structions, (i) we disallow the control flow through that func-tion, and (ii) we import all the tags from that function on eachinvocation. The following theorem bounds the complexity ofthe PNR algorithm.
main, NEW, [1]
main, INVOKESTATIC, [1]
bar, LOAD_REFERENCE, [1, 2]
bar, IFNONNULL, [1,2]
bar, LOAD_REFERENCE, [1,2]
bar, IFNONNULL, [1,2]
bar, NEW, [2]
bar, STORE_REFERENCE, [2]
bar, LOAD_REFERENCE, [1, 2]
bar, PUTSTATIC, [1,2]
bar, GOTO
main, RETURN
bar, RETURN
bar, INVOKESTATIC, [3, 4]
main, INVOKESTATIC, [3, 4]
Figure 2. Instruction-Graph of an example thread: Eachnode represents a bytecode instruction and contains allpossible tags that may be used during the execution ofthat instruction. The nodes are labeled with the nameof the containing function, the instruction mnemonic,and the tags contained. The graph alludes to two func-tions main and bar. Two rectangular nodes indicatethe invocation of a third function call2Times throughwhich the control flow is avoided as an optimization (Sec-tion 4.1.2).
THEOREM 4.1.1. The worst case time complexity of thePNR algorithm is O(|T | · (|V |+ |E|)) ≤ O(|V | · (|V |+ |E|)),where V and E are the nodes and edges in the Instruction-DAG and T is the set of tags.PROOF. First note that the number of tags is bounded by |V |because a node can create at most one tag. The topologicalordering of a DAG can be computed in time O(|V |+ |E|).
For the computation of the bitmaps BMv each edge of thegraph causes at most |T | operations for updating the bitmapsfrom the successors plus |T | operations for initializing thebitmaps. This causes a runtime of O(|T | · (|V |+ |E|)).
Analogously, the computation of all PNR needs the sameamount of operations: Each edge is processed only once and
causes |T | operations for checking the bitmaps. So, the re-sulting worst case time is O(|T | · (|V |+ |E|)).
4.1.3 ExampleAn example Instruction-Graph of a program thread is
shown in Fig. 2. The rectangular nodes indicate the invo-cation of a function call2Times with maximum call limitn = 1 (see Section 4.1.2). The corresponding DAG on whichthe PNR algorithm operates is shown in Fig. 3. In this exam-ple, the PNR of tag 1 and tag 2 is the INVOKESTATIC instruc-tion, shown in the rectangular node. From this node onwardin the control flow, these two tags are guaranteed to remainunused. Similarly, the RETURN instruction of the main func-tion is the PNR for tag 3 and tag 5.
main:NEW, Tags:[1]
main:INVOKESTATIC, Tags:[1]
bar:LOAD_REFERENCE, ..., bar:GOTO, Tags:[1, 2]
main, RETURN
bar, RETURN
bar:INVOKESTATIC, Tags:[3, 4]
main:INVOKESTATIC, Tags:[3,4]
Figure 3. DAG of an Instruction-Graph: Showing theDAG of the Instruction-Graph of Fig. 2. The stronglyconnected component from Fig. 2 has been replaced witha single composite node.
4.2 Algorithm 2: FTT (Finding the Tail)The FTT algorithm operates on the Function-Call-Graph
of a thread. It makes the deallocation decisions for objectsthat would be stored, at runtime, only in local variables (andnever in a field). By definition, a tag for such objects is gen-erated by a bytecode instruction in exactly one function. Foreach appearance of that generating function, we can find sub-graphs, disconnected from each other, in the Function-Call-Graph such that:
1. Each node representing the function that generates agiven tag is included in exactly one subgraph.
2. Each node in the subgraph uses the given tag.
3. Any node that is not part of a subgraph and is directlyconnected to it must not use the given tag.
The FTT algorithm is designed to find the tail of eachsubgraph. The tail of the subgraph is a node which representsa function that is the last to use a given tag. This function: (i)contains the instruction which either generates this tag, or in-vokes another function which returns this tag, and (ii) neitherreturns this tag nor receives this tag as input parameter.
Once the FTT algorithm determines the tail of a sub-graph, it calls upon the PNR algorithm on the DAG of theInstruction-Graph of the function represented by the tail.The PNR algorithm may successfully identify the insertion
point of the OFFLINE GC FREE instruction; otherwise, theOFFLINE GC FREE instruction is inserted immediately afterthe instruction that invoked the function represented by thetail. The pseudocode of the complete algorithm is:
Algorithm 2 Finding the Tail (FTT)
1: Compute FG as the Function-Call-Graph of a thread2: for each tag element t which is never stored in a field do3: Compute the induced subgraph FG(t) of FG by the
nodes which use t4: Determine all recursive vertices in FG(t), i.e. nodes v
in FG(t) for which a directed path starting and endingat v exists in FG(t)
5: for each vertex v ∈ FG(t) do6: if v represents a tail method m for t then7: if v is not recursive then8: Create the DAG G′ of the Instruction-Graph of
v9: Apply PNR algorithm on G′ for tag t
10: else11: for predecessor w∈V (FG)\V (FG(t)) of v do12: Add OFFLINE GC FREE instruction for tag t
on w immediately after the instruction thatinvoked m
13: end for14: end if15: end if16: end for17: end for
4.2.1 Strengths and LimitationsThe FTT algorithm, unlike the PNR algorithm, may have
visibility into the strongly connected components of theInstruction-Graph of a thread. It also works for programsthat never exit and even can free references inside the loopwithin which they are used. The main limitation of this al-gorithm is that it cannot free any reference that is ever storedin a field.
4.2.2 ScalabilityThe time complexity of FTT is O(|T |(|V ′|+ |E ′|+ |V ′′|+
|E ′′|)) where T is the set of tags, V ′ and E ′ are the nodes andedges of the Function-Call Graph, V ′′ and E ′′ are the maxi-mum number of nodes and edges of the Instruction graph ofa method. Since the Function-Call Graph and the Instructiongraph of a method are very small compared to the instruc-tion graph of a thread. Therefore, O(|T |(|V ′|+ |E ′|+ |V ′′|+|E ′′|))< O(|T |(|V |+ |E|)) where |V | and |E| are the numberof the nodes and edges of the Instruction graph of the thread.
4.2.3 ExampleAn example Function-Graph is shown in Fig. 4 which
shows that the FTT algorithm will free the tags as follows:The tags 1, 2, and 3 will be deallocated inside its tail func-tion named main and the tag 5 will be deallocated on its tailfunction TimeConstruction. The tag 4 is deallocated im-mediately after the instructions invoking Populate, in themain and TimeConstruction.
main, Tags:[1,2,3]
TimeConstruction, Tags:[1,5] Populate, Tags:[3,4]
NumIters, Tags:[5] Populate, Tags:[4,5]
TreeSize, Tags:[5] TreeSize, Tags:[5]
Figure 4. Function-Call-Graph of a thread: Each nodecontains all possible tags used in the correspondingFunction-Call.
4.3 Algorithm 3: DAU (Disconnect All Uses)The DAU algorithm can free a reference inside the loop
where it is used, even if such a reference is assigned to afield. The basic idea of this algorithm is as follows: if aninstruction r that creates a tag is deleted from the Instruction-Graph of the program and all the nodes using that tag becomeunreachable from the root of that graph, then each objectassigned with that tag is guaranteed to be overwritten eachtime the instruction r is executed, provided the tag is storedin exactly one variable, (i.e., either in a single non-array fieldor in a local variable).
Algorithm 3 Disconnect All Uses (DAU)
1: Consider the Instruction-Graph G = (V,E) of a thread2: for each tag t that is never stored in multiple variables
do3: Lookup v ∈V as the instruction (node) that creates t4: Compute Gv = (V \{v},E ′)5: Compute the set Rv of all reachable nodes in Gv from
the root node6: if no node in Rv is using t then7: Create a DAG D of the subgraph induced by the
nodes V \ Rv of G (containing only unreachablenodes)
8: Apply PNR algorithm on the DAG D for tag t9: end if
10: end for
4.3.1 Strengths and LimitationsThis algorithm can free a reference inside the loop in
which it is used, even if such a reference is assigned to afield. The main limitation is that it cannot free a referenceassigned to more than one variable.
4.3.2 ScalabilityThis section discusses scalability of the DAU algorithm.
We start by proving its time complexity.THEOREM 4.3.1. The time complexity of DAU algorithmis O(|T | · (|V |+ |E|)) ≤ O(|V | · (|V |+ |E|)), where V and Eare the vertices and edges of the instruction-graph and T isthe set of all tags.PROOF. Recall that the number of tags is bounded by thenumber of nodes |V | of the instruction graph. A reverselookup of the creating node can be done in constant timeafter once creating the table in time O(|V |).
Computing the sub-graphs Gv and the DAG D can bedone in |V |+ |E| since this can be done by a depth-first-
search in G. Finally, the application of PNR requires onlyO(|V |+ |E|) time since we consider only one tag using The-orem 4.1.1.Dealing with threads: Each of the three algorithms (PNR,FTT, and DAU) ascertains as to when a tag can be freed.However, since the thread switching order is unknown atcompile time, tags common to multiple threads are left aloneby these algorithms.
5 Runtime ImplementationThe first two phases of Offline GC, the data-flow analysis
phase and the bytecode updating phase, are part of programcompilation. This third and final phase of Offline GC is car-ried out at runtime. This phase can be implemented on anyavailable JVM interpreter. We have selected the TakaTukaJVM [3] because it is open source and it works on tiny plat-forms where Offline GC is most useful in saving scarce re-sources. In the following subsections we highlight the designgoals of the Offline GC runtime implementation and the sup-port needed from a JVM interpreter to achieve these goals.While Offline GC aims at saving the required runtime mem-ory, its implementation calls for a small memory overhead atruntime, as characterized in the discussion below.
5.1 Freeing a Group of ObjectsOffline GC assigns a unique tag to all the objects created
by a single instruction, as described in Section 3. A JVMinterpreter must execute the OFFLINE GC FREE <TAG> in-struction at runtime to free all the objects that are assignedwith the tag specified in the instruction operand. A goal ofimplementing the OFFLINE GC FREE instruction is that theinterpreter should be able to free all the objects with a giventag efficiently. To this end, all the objects with a given tagshould be grouped together and the group must be deallo-cated without traversing the complete object graph.
During program execution, all objects with a given tagare linked together by using a doubly-linked list. For eachtag, the reference of the first object in the associated doubly-linked list is stored in an array called Representative Ref-erence Array (RRA). The length of this array is, therefore,equal to the number of tags identified during OGC-DFA. Theelement at index i of the RRA stores the reference to the firstelement of the doubly-linked list associated with tag i. Us-ing the RRA, all the objects grouped by a given tag can bereached with the time complexity of O(n), where n is num-ber of objects which are assigned with that tag at runtime.To deallocate the objects grouped by a tag, the doubly-linkedlist associated with that tag is traversed, instead of a completetraversal of the object graph.Memory Overhead: The size of the RRA, the static arraywhich stores one reference per tag is 2γ bytes, where γ isthe total number of tags while each reference takes 2 bytes.Furthermore, to create the doubly-linked list, an additional 4bytes per object are required.
5.2 Conflict with Online GCA typical online GC only frees an object if it is unreach-
able and cannot be reached during the traversal of the objectgraph. Thus, an online GC may need to traverse the objectgraph each time it is invoked. In contrast, Offline GC can
Figure 5. IRIS Mote: An IRIS mote used in our experi-mental evaluation. The mote has 128 KB of flash, 8 KB ofRAM, and it uses an 8-bit AtMega128L processor. It ispowered by two AA batteries and is equipped with a 2.4GHz radio for communication with other motes.
free an object that may be reachable but will never be usedin future. When an object that is reachable is deallocatedby Offline GC then the reference to this object becomes in-valid and a subsequent invocation of online GC is likely toreport memory errors when it reaches the invalid referenceduring traversal of the object graph. Our implementationavoids such errors as follows:
When an object is deallocated by the OFFLINE GC FREE
instruction, the value of the corresponding reference (i.e., thememory location) is stored in a dynamic table. When an on-line GC traverses the object graph, the value of each encoun-tered reference is first looked up in the dynamic table. If thetable contains a reference value, indicating that the memorylocation pointed to by that reference value has already beenfreed by Offline GC, the online GC does not dereference thatvalue. The online GC also sets each variable storing suchreferences to null. Thus, at the end of each invocation ofonline GC, all entries in the dynamic table containing thereference values can be deleted.Memory Overhead: The size of the dynamic table is 2δbytes (assuming that a reference occupies 2 bytes), where δis the number of objects that are deallocated by Offline GCsince the last invocation of the online GC. The table entriesare removed at the completion of each online GC cycle.
6 Results and DiscussionThe use of Offline GC offers two main advantages as
compared to when only a traditional, online garbage col-lector is used: (1) additional RAM is made available for auser Java program, and (2) the number of CPU cycles con-sumed in deallocating objects at runtime is reduced, resultingin an increased battery lifetime of the host device. These ad-vantages come with two drawbacks: (1) the increased flashstorage requirement, and (2) a longer compilation time of aprogram. We first describe the programs used to measure thecharacteristics of Offline GC.
6.1 Benchmark ProgramsWe have implemented Offline GC on the TakaTuka
JVM [3]. This JVM supports wireless sensor motes whichtypically have at the most 10 KB of RAM and 128 KBof flash storage. Many existing GC benchmarks, such asSPECjbb2005, SPECjvm2008 and EEMBC [15, 16], oran arbitrary Java program cannot be selected to run onsuch a resource-constrained device. For our evaluation weneeded benchmarks developed for resource constrained sen-sor motes or are flexible enough to reduce their defaultmemory requirements. We found two such GC benchmarks
Benchmark Brief Evaluation
Name Description Platform
JTC JVM Test Cases. Taken from the TakaTuka Sourceforge repository. Mica2, Avrora
Includes hundreds of test cases. The test cases are developed to
check the Java binary instructions set implementation of a JVM.
GCBench Designed to mimic memory usage behavior of real applications. Mica2, Avrora
Default RAM requirement is 32 MB. To fit the benchmark onto a tiny mote
with 4 KB RAM, we used the following input parameters: kStretchTreeDepth=7,
kLongLivedTreeDepth=25, kArraySize=100, kMinTreeDepth=4,
and kMaxTreeDepth=10.
A description of these parameters may be obtained from the source code [12].
The benchmark creates a mix of long and short lived objects.
The short lived objects are binary trees. To constrain the memory,
we changed the binary tree structure to a linked list.
GCOld A GC benchmark developed at Sun Microsystems for Mica2, Avrora
garbage collection research [12].
It creates binary trees for short and long lived objects.
We have changed the following parameters so that it can run
on a tiny mote using a few KBs of RAM: MEG=2, INSIGNIFICANT=5,
BYTES PER WORD=1, BYTES PER NODE=1, treeHeight=4, size=14,
workUnits=20, promoteRate=2, ptrMutRate=5, and steps=20.
A description of these parameters may be obtained from
the implementation of GCOld [12].
QuickSort The in-place iterative implementation of the Quicksort algorithm. Mica2, Avrora
Each iteration creates very few dynamic objects. This program is selected
to show that Offline GC is to be used with caution;
it may not be beneficial if a program has only a few dynamic objects.
CTP Taken from the TakaTuka sourceforge repository. IRIS (see Fig. 5)
CTP is an address-free routing protocol for networks that use
wireless sensor motes [13]. The protocol is completely implemented
using Java and uses four threads.
DYMO Taken from the TakaTuka sourceforge repository. DYMO is a successor to IRIS
the Ad hoc On-Demand Distance Vector (AODV) routing protocol [14].
The protocol is completely implemented using Java with threads.
Table 1. Benchmarks used for the evaluation of Offline GC.
namely GCBench and GCOld [17, 12] whose RAM require-ments were dependent upon their input parameters. In ad-dition to these two benchmarks, we have also used threeexisting applications from the TakaTuka JVM sourceforgerepository. These applications have been developed for theresource constraints of sensor motes. Table 1 provides a de-scription of these five benchmarks, which are used for theevaluation of Offline GC.
6.2 Evaluation ResultsThis section provides an evaluation of Offline GC on the
first four benchmarks in Table 1. We evaluated these bench-mark programs on Crossbow Mica2 motes [1, 18] as wellas on Avrora which is a simulator for the Mica2 motes [19].
The memory usage results for the actual Mica2 motes andthe Avrora simulator were found to be consistent with eachother. For measuring the CPU cycles consumed in deallocat-ing the objects, we used only the Avrora simulator because itis hard to measure the CPU cycles on an actual sensor mote.Avrora simulates microcontroller instructions and can accu-rately calculate the CPU cycles consumed by a set of proce-dures during the execution of a program. In order to preservethe correlation of memory usage with CPU cycles, both ofthese results are presented using the Avrora simulator.
6.2.1 RAM Availability
The results for RAM-available at a point of executionwith and without the use of Offline GC have been shown
(a) JTC (b) GCBench (c) GCOld
Figure 6. RAM-available: The amount of RAM-available in bytes at different points of execution for the first threebenchmarks given in Table 1.
in Fig. 6. The term RAM-available at a given point of execu-tion refers to the maximum amount of memory that becomesavailable to a program if a precise compacting online GC isexecuted at that point. Thus, at every execution point, theactual free memory will always be less than or equal to theRAM-available at that point. Furthermore, if RAM-availableat a point is 0 bytes, then a program is deemed to be outof memory. It can no longer continue its execution becauseeven running a GC at that point will not free any additionalmemory.
Fig. 6 shows the RAM-available at different points of ex-ecution of the JTC, GCBench, and GCOld benchmarks. TheJVM Test Cases (JTC) program consists of many test cases,each executing one after the other. Therefore, many dynamicand independent objects are created during the execution ofJTC. It is because of the presence of excessive dynamic andindependent objects, that JTC on average has 42.37% addi-tional RAM-available during the program execution if Off-line GC is used. The GCBench and GCOld programs have,on average, 81.88% and 32.81% additional RAM availablerespectively when Offline GC is used. Both of these pro-grams have long-lived objects that are created at the start oftheir execution but are not used afterwards. As these objectsare in-scope (reachable) during almost the entire program ex-ecution hence they cannot be freed by the online GC. In con-trast, Offline GC deallocates these objects soon after theirlast use, even when they are still reachable. Furthermore,many short-lived objects are also freed by Offline GC a fewbytecode instructions ahead of the execution point when anonline GC would free them. However, a short lasting in-crease in RAM-availability like this is not captured in theRAM-availability graphs of these benchmarks.
Finally, Fig. 7 shows that in-place Quicksort performsbetter when Offline GC is not used. This is because thisbenchmark creates very few (only three) dynamic objectsduring each iteration for sorting a subset of the input array.None of these objects can be freed by Offline GC earlier thanthe execution point when a regular online GC would freethem. In this case, the RAM-available is 0.6% smaller ifOffline GC is used. This reduction is due to the implementa-tion overhead of Offline GC as explained in Section 5. Thisoverhead is present in all the programs and is visible at thebeginning of each graph in Fig. 6. However, for a program
that creates many dynamic objects, this overhead is usuallynegligible as compared to the additional memory made avail-able by Offline GC. In conclusion, Offline GC is effective inbringing down RAM utilization for programs that create sev-eral large dynamic objects, each larger than 4 bytes. Thus,for a given program, Offline GC has to be used with caution.
(a) RAM-Available
(b) CPU Cycles
Figure 7. The RAM-available in bytes at different pointsof execution and number of CPU cycles consumed indeallocating objects, for the Quicksort program with andwithout the use of Offline GC.
6.2.2 CPU CyclesThe TakaTuka JVM uses a mark-and-sweep online GC
with compaction [5, 20]. Considering that the amount ofRAM available on motes is limited, the online GC forTakaTuka is designed to be memory efficient by choosing a
(a) JTC (b) GCBench (c) GCOld
Figure 8. CPU Cycles: The number of CPU cycles consumed in deallocating objects during the execution of a program,with and without the use of Offline GC.
Benchmark with Offline GC without
JVM Test Cases 8 47
GCBench 16 44
GCOld 0 18
QuickSort 12 13
CTP Root 27 53
CTP Non-Root 32 34
DYMO Source 11 29
DYMO Dest. 13 13
Table 2. The number of times online GC is called by thebenchmark programs, with and without Offline GC. TheCTP results are produced with inflated objects’ size whilereceiving 25 data packets at the Root node.
Benchmark % reduction in CPU cycles
JVM Test Cases 8.17
GCBench 9.65
GCOld 4.52
QuickSort −0.21
Table 3. The overall percentage reduction in the numberof CPU cycles with Offline GC.
Extra with Offline GC
Max #objects Bytes RAM in
in RAM per object bytes
CTP Root 63 7 7×63 = 441
CTP Non-Root 57 3 3×27 = 171
DYMO Source 45 7 7×45 = 315
DYMO Dest. 48 2 2×48 = 96
Table 4. Extra RAM-available at each node for CTPand DYMO with the use of Offline GC (shown in thelast column). First column shows the maximum numberof reachable objects at any time during the execution ofthe respective program. Second column shows the differ-ential increase (in bytes) in size of each object with andwithout Offline GC.
non-recursive implementation with multiple iterations of theheap. During a single invocation, the overall time consumedby the online GC is O(k+b2), where b is the number of ob-jects on the heap and k is the current size of all stack-frames.In order to minimize the CPU cycle consumption, the on-line GC is executed only when it is necessary, i.e., when theRAM is nearly full. By deallocating objects at regular inter-vals, Offline GC reduces the number of times an online GCneeds to be invoked (see Table 2 for comparative results ofthe benchmarks). This leads to a reduction in the number ofCPU cycles consumed when Offline GC is used as shown inFig. 8 and Table 3. The reduction in the number of CPU cy-cles needed to free objects is 60.56%, 63.48%, and 94.59%for JTC, GCBench, and GCOld, respectively (Fig. 8). Thistranslates into a reduction of 8.17%, 9.65% and 4.52% in theoverall CPU cycles required for JTC, GCBench and GCOld,respectively (Table 3). On the other hand, the Quicksort pro-gram takes 0.21% extra CPU cycles when Offline GC is used(Table 3 and Fig. 7). This again is because, in case of in-place Quicksort, very few dynamic objects are created andthus the performance gain of Offline GC does not exceedthe overhead associated with maintaining it. This results inan increased CPU cycles consumption due to the overheadassociated with the execution of the OFFLINE GC NEW andOFFLINE GC FREE instructions.
6.3 Routing Protocols: CTP and DYMOThis section presents performance results of Offline GC
for two popular routing protocols – collection tree protocol(CTP) [13] and Dynamic MANET On-demand Routing Pro-tocol (DYMO) [14].
CTP is a tree-based routing protocol in which a few net-work nodes advertise themselves as root of the network [13].Based on such advertisements, each non-root node deter-mines which of its neighbors is either a root or nearer to oneof the roots. In steady state operation of CTP, a set of dis-tributed routing trees exists with each such tree comprisinga root node and several non-root nodes. CTP is an address-free protocol in which the data is always transmitted from anon-root towards the nearest root node which is part of thesame routing tree.
The Java implementation of CTP, available in theTakaTuka Sourceforge repository, has a memory require-ment of more than 4 KB. Since Avrora only supports Mica2
simulation with a maximum RAM size of 4 KB, we could notuse Avrora as the evaluation platform for benchmarking Off-line GC with CTP. Instead, we used IRIS motes (see Fig. 5)equipped with 8 KB of RAM [1].
The Java CTP implementation uses four threads, some ofwhich wait to receive the data or control packets. This im-plies that the bytecode instructions of the program are notexecuted in a deterministic order, and thus memory usageresults, similar to those in Fig. 6 cannot be produced in thiscase. Therefore, our evaluation of Offline GC with CTP pro-ceeds as follows. We run the benchmark program repeat-edly, incrementing the size of all objects by one byte in eachsuccessive run. The goal is to find the maximum possibleincrease of object size before we reach a point where theprogram exceeds the RAM of the mote. Table 4 indicatesthat when Offline GC is used, 441 and 171 additional bytescan be occupied by objects for the root and non-root motes,respectively, as compared to the case when only the onlineGC is used. This implies that a bigger applications can bedeveloped over CTP if Offline GC is used. Furthermore, itis shown in Table 2 that the use of Offline GC results in areduction in the number of times the online GC is needed tobe invoked, thus saving the CPU cycles and hence increasingthe battery life of a wireless sensor mote.
Results obtained for DYMO were similar to those forCTP when we used the same experimental procedure. Ta-ble 4 indicates that 315 bytes of extra RAM are availablewhen Offline GC is used for a source node in DYMO and 96extra bytes for a destination node.
6.4 Efficacy and LimitationsThe effectiveness of using Offline GC is quite prominent
for programs that create many large-sized objects. The useof Offline GC does not come for free. That is, the flashstorage requirement is increased and the program will takelonger to compile. The increase in flash storage requirementis due to two reasons. First, the size of the Java binary getsinflated due to the insertion of the two new bytecode instruc-tions (OFFLINE GC NEW and OFFLINE GC FREE). Second, thesize of the Java interpreter is also increased when it providesthe implementation of these two new instructions.
Fig. 9 shows that, for the benchmarks we used, the aggre-gated size of the Java binary and the interpreter increases onthe average by 3.63 %. This implies that Offline GC does notnot increase the flash storage requirements of a mote signif-icantly and it is feasible to use it on a tiny mote device withlimited storage.
Fig. 9 also shows the time taken in compilation of a pro-gram with the use of Offline GC. Before transferring the codeon to a mote, the compilation was carried out on a typicalnotebook with AMD Athlon II P320 / 2.1 GHz processorand 4 GB of RAM. The maximum compilation time takenby a program to compile with Offline GC was 24.33 secondsand average compilation time was 11.5 second for the givenset of program. It included the time taken by both of the firsttwo phases of Offline GC as well as the time for changingthe bytecode. We believe that this compilation delay is toler-able given that it results in increasing a program’s executionspeed and reducing its RAM consumption.
(a) Flash Size
(b) Compilation Time
Figure 9. Fig. (a) shows the aggregated size of Java bi-nary and interpreter (Flash size). Fig. (b) shows the timetaken by various components of Offline GC during thefirst two phases of program compilation before transfer-ring the code on to a mote.
7 Related WorkThe notion of compile-time garbage collection goes back
to Barth [21] who proposed a scheme for maintaining refer-ence counts at compile time. This topic has been picked upand improved upon by later researches, e.g., [22, 23]. How-ever, this strand of work differs from our proposal which istargeted at mark-and-sweep GC.
Free-me [7] is a static analysis that identifies the ob-jects when they become dead, and inserts code to free them.Unlike Offline GC it is based on flow-insensitive and field-insensitive pointer analysis, thus it is suitable mostly for localvariables. Furthermore, Free-me puts the main emphasis onreclaiming short-lived objects, whereas our analysis handlesthe long-lived objects also.
Shaham et al. [24] provide a yet more precise analysis forplacing free instructions. Their approach can even deallocatean object when it is still reachable; however their analysis isintra-procedural and rather expensive in practice.
Agesen el al. [25] have also applied type analysis andliveness analysis, but its application is to shrink the root setfor a garbage collector. They do not insert explicit free in-structions.
The scheme proposed by Cherem et al. [26] is closest toour work as it updates the program bytecode using a flow-sensitive and inter-procedural pointer analysis. The mainlimitation of this scheme is that it allows deallocating onlythose objects that are not shared by multiple fields or localvariables at the function boundaries. Thus it cannot deallo-cate objects that are saved in multiple variables and used bymultiple methods. Offline GC overcomes this limitation by
keeping static and non-static field data structures during theanalysis phase.
A further area of related work is based on escape analy-sis [8, 9, 10] which determines whether objects can escapefrom their defining scope. The main application of escapeanalysis is to determine which objects can safely be allocatedon the runtime stack. This allocation is static and the cor-responding deallocation is automatic when the function ex-its. Besides speeding up the program by avoiding the cost ofmemory management for non-escaping objects, there is alsono need to synchronize on such objects as they stay withina thread. While escape analysis speeds up program execu-tion, it may lead to memory leaks because a stack-allocatedobject cannot be freed before the function returns. In con-trast, a heap-allocated object could be freed as soon as it be-comes inaccessible. Thus, escape analysis trades executionspeed for space. In contrast, the main goal of Offline GCis to reduce the memory consumption of a program withoutcompromising its execution speed.
Offline GC is also related to region-based memory man-agement [27]. Each allocation site gives rise to its own re-gion of memory (identified by a tag, following Jones andMuchnick [28]), which is freed when our analysis deter-mines that all references to this region are dead. As with re-gion analysis, our analysis can also free objects that are stillreachable and thus would not be reclaimed yet by garbagecollection.
Much of the work on regions is based on static analysis[29, 30], but there is also work supporting explicit manualregion management [31]. While original work supports re-gion deallocation only in a stack-like manner, the subsequentwork supports more fine-grain control over the placement ofdeallocation.
8 ConclusionsWe have designed and presented a software optimiza-
tion for tiny embedded devices that moves the bulk of Javagarbage collection offline. Offline GC brings two benefits: itallows running feature-rich large Java programs and it saveson CPU cycles to run a given program thus extending thebattery life of such devices that usually operate on batterypower.
We have also presented three algorithms to facilitate off-line deallocation decisions. These algorithms identify wherein the program execution an object, which would be leftalone by a traditional garbage collector, may be deallocated.Working independently, these algorithms suit different typesof programs. Thus, using one or more of these algorithms, avariety of programs can benefit from the use of Offline GC.
We performed an evaluation of Offline GC using manyprograms including the two well-known GC benchmarksand two popular wireless sensor network routing protocol.Our results indicate that Offline GC can reduce the overallCPU cycles required to run a program up to about 10%,while making up to 82% extra RAM available by deallo-cating reachable objects that cannot be deallocated by anytypical online GC. Offline GC is the most useful for applica-tions which allocate many dynamic objects, each larger than4 bytes. In contrast, applications which reuse same set of
small-footprint objects do not benefit much. For example,the in-place Quicksort, which reuses the same array to sortall objects and makes few dynamic objects, consumes 0.6%additional RAM with Offline GC due to the memory over-head of its runtime implementation. Thus, while Offline GCbenefits most sensor application, we caution against its usewhen a program has very few dynamic objects.
Although Offline GC is primarily developed for resourceconstrained devices, it is also useful for powerful computersrunning large applications. The results of RAM availabilitypresented in this paper are independent of the online GC usedby a device and the resources available on such a device. Itimplies that the results presented in Fig. 6 will remain un-changed, if an online GC other than mark-and-sweep is em-ployed on a device with plenty of resources. Furthermore,Offline GC should also scale to large programs developedfor powerful computers because each of the three algorithmsdesigned for making the offline deallocation decisions haspolynomial time complexity and RAM requirements. Typi-cal programs developed for powerful computers create manylarge-sized dynamic objects, a situation in which Offline GCis the most beneficial.
9 Acknowledgements
This work is supported in part by the Higher EducationCommission (HEC) of Pakistan, the University of Freiburg,and the Max Planck Institute for Software Systems. The au-thors would like to thank their shepherd John Regehr and theanonymous reviewers for their useful comments.
10 References[1] ETH Zurich. The Sensor Network Museum.
http://www.snm.ethz.ch/Main/HomePage, [Last Ac-cessed: 15.08.2011].
[2] Niels Brouwers, Koen Langendoen, and Peter Corke. Darjeel-ing, a Feature-Rich VM for the Resource Poor. In Proceedingsof the 7th ACM Conference on Embedded Networked SensorSystems, SenSys ’09, pages 169–182, New York, NY, USA,2009. ACM.
[3] Faisal Aslam, Luminous Fennell, Christian Schindelhauer,Peter Thiemann, Gidon Ernst, Elmar Haussmann, StefanRuhrup, and Zastash Afzal Uzmi. Optimized Java Binary andVirtual Machine for Tiny Motes. In Distributed Computingin Sensor Systems (DCOSS), volume 6131, chapter 2, pages15–30. Springer Berlin Heidelberg, Berlin, Heidelberg, 2010.
[4] Janice J. Heiss. Sentilla’s Pervasive Computing – The Uni-verse Is the Computer. 2008 JavaOne Conference.
[5] Richard Jones and Rafael Lins. Garbage Collection: Algo-rithms for Automatic Dynamic Memory Management. JohnWiley & Sons, September 1996.
[6] Sigmund Cherem and Radu Rugina. Uniqueness Inferencefor Compile-Time Object Deallocation. In Proceedings of the6th international symposium on Memory management, ISMM’07, pages 117–128, New York, NY, USA, 2007. ACM.
[7] Samuel Guyer, Kathryn McKinley, and Daniel Frampton.Free-Me: A Static Analysis for Automatic Individual ObjectReclamation. In Proceedings of the 2006 ACM SIGPLANConference on Programming Language Design and Imple-mentation, PLDI ’06, pages 364–375, New York, NY, USA,2006. ACM.
[8] Elvira Albert, Samir Genaim, and Miguel Gomez-Zamalloa.Heap Space Analysis for Java Bytecode. In Proceedings ofthe 6th International Symposium on Memory Management,ISMM ’07, pages 105–116, New York, NY, USA, 2007.ACM.
[9] Jong-Deok Choi, Manish Gupta, Mauricio Serrano, Vu-granam C. Sreedhar, and Sam Midkiff. Escape Analysis forJava. In Proceedings of the 14th ACM SIGPLAN Confer-ence on Object-Oriented Programming, Systems, Languages,and Applications, OOPSLA ’99, pages 1–19, New York, NY,USA, 1999. ACM.
[10] Bruno Blanchet. Escape Analysis for JavaTM: Theory andPractice. ACM Transactions on Programming Languages andSystems (TOPLAS), 25:713–775, November 2003.
[11] Tim Lindholm and Frank Yellin. Java Virtual Machine Spec-ification. Addison-Wesley Longman Publishing Co., Inc.,Boston, MA, USA, 2nd edition, 1999.
[12] Source code. GCBench and GCOld benchmarks.http://www.cs.cmu.edu/˜spoons/gc/benchmarks.html,[Last Accessed: 15.08.2011].
[13] Omprakash Gnawali, Rodrigo Fonseca, Kyle Jamieson, DavidMoss, and Philip Levis. Collection Tree Protocol. In Pro-ceedings of the 7th ACM Conference on Embedded NetworkedSensor Systems, SenSys ’09, pages 1–14. ACM, 2009.
[14] Ian Chakeres and Charles Perkins. Dynamic MANET On-demand (DYMO) Routing. IETF (work in progress), 2010.
[15] David Bacon, Perry Cheng, and David Grove. Garbage Col-lection for Embedded Systems. In Proceedings of the 4thACM International Conference on Embedded Software, EM-SOFT ’04, pages 125–136, New York, NY, USA, 2004. ACM.
[16] Kumar Shiv, Kingsum Chow, Yanping Wang, and DmitryPetrochenko. SPECjvm2008 Performance Characterization.In Proceedings of the 2009 SPEC Benchmark Workshop onComputer Performance Evaluation and Benchmarking, pages17–35, Berlin, Heidelberg, 2009. Springer-Verlag.
[17] Daniel Spoonhower, Guy Blelloch, and Robert Harper. Us-ing Page Residency to Balance Tradeoffs in Tracing GarbageCollection. In Proceedings of the 1st ACM/USENIX Interna-tional Conference on Virtual Execution Environments, VEE’05, pages 57–67, New York, NY, USA, 2005. ACM.
[18] Crossbow Technology. Wireless Sensor Networks.http://www.xbow.com, [Last Accessed: 15.02.2011].
[19] Ben Lawrence Titzer, Daniel Lee, and Jens Palsberg. Avrora:Scalable Sensor Network Simulation with Precise Timing. InProceedings of the 4th International Symposium on Informa-tion Processing in Sensor Networks, IPSN ’05, Piscataway,NJ, USA, 2005. IEEE Press.
[20] Luminous Fennell. Garbage Collection for TakaTuka, Bache-lors Thesis. University of Freiburg, Germany, 2010.
[21] Jeffrey Barth. Shifting Garbage Collection Overhead to Com-
pile Time. Communications of the ACM (CACM), 20:513–518, July 1977.
[22] Pramod Joisha. Overlooking Roots: A Framework for MakingNondeferred Reference-Counting Garbage Collection Fast. InProceedings of the 6th International Symposium on MemoryManagement, ISMM ’07, pages 141–158, New York, NY,USA, 2007. ACM.
[23] Wolfram Schulte. Deriving Residual Reference CountGarbage Collectors. In Symposium on Programming Lan-guage Implementation and Logic Programming (PLILP),pages 102–116. Springer-Verlag, 1994.
[24] Ran Shaham, Eran Yahav, Elliot Kolodner, and Mooly Sagiv.Establishing Local Temporal Heap Safety Properties with Ap-plications to Compile-Time Memory Management. In StaticAnalysis, volume 2694 of Lecture Notes in Computer Science,pages 483–503. Springer Berlin / Heidelberg, 2003.
[25] Ole Agesen, David Detlefs, and J. Eliot Moss. Garbage col-lection and local variable type-precision and liveness in Javavirtual machines. In Proceedings of the ACM SIGPLAN 1998Conference on Programming Language Design and Imple-mentation, PLDI ’98, pages 269–279, New York, NY, USA,1998. ACM.
[26] Sigmund Cherem and Radu Rugina. Compile-Time Deallo-cation of Individual Objects. In Proceedings of the 5th In-ternational Symposium on Memory Management, ISMM ’06,pages 138–149, New York, NY, USA, 2006. ACM.
[27] Dan Grossman, Greg Morrisett, Trevor Jim, Michael Hicks,Yanling Wang, and James Cheney. Region-Based MemoryManagement in Cyclone. In Proceedings of the ACM SIG-PLAN 2002 Conference on Programming Language Designand Implementation, PLDI ’02, pages 282–293, New York,NY, USA, 2002. ACM.
[28] Neil Jones and Steven Muchnick. Flow Analysis and Opti-mization of LISP-like Structures. In Proceedings of the 6thACM SIGACT-SIGPLAN Symposium on Principles of Pro-gramming Languages, POPL ’79, pages 244–256, New York,NY, USA, 1979. ACM.
[29] Alexandru Stefan, Florin Craciun, and Wei-Ngan Chin. AFlow-Sensitive Region Inference for CLI. In Proceedings ofthe 6th Asian Symposium on Programming Languages andSystems, APLAS ’08, pages 19–35, Berlin, Heidelberg, 2008.Springer-Verlag.
[30] Sigmund Cherem and Radu Rugina. Region Analysis andTransformation for Java Programs. In Proceedings of the 4thInternational Symposium on Memory Management, ISMM’04, pages 85–96, New York, NY, USA, 2004. ACM.
[31] David Gay and Alex Aiken. Memory Management with Ex-plicit Regions. In Proceedings of the ACM SIGPLAN 1998Conference on Programming Language Design and Imple-mentation, PLDI ’98, pages 313–323, New York, NY, USA,1998. ACM.