Garbage Collection in Object Oriented Databases Using Transactional Cyclic Reference Counting S. Ashwinl* Prasan Roy’ S. Seshadri’ Avi Silberschatz2 S. Sudarshanl ‘Indian Institute of Technology, ‘Bell Laboratories Mumbai 400 076, India Murray Hill, NJ 07974 [email protected] [email protected] {prasan,seshadri,sudarsha}@cse.iitb.ernet.in 1 Introduction Abstract Object oriented databases (OODBs), unlike relational databases, support the notion of object identity, and objects can refer to other objects via object identifi- Garbage collection is important in object- ers. Requiring the programmer to write code to track oriented databases to free the programmer objects and their references, and to delete objects that from explicitly deallocating memory. In this are no longer referenced, is error prone and leads to paper, we present a garbage collection al- common programming errors such as memory leaks gorithm, called Transactional Cyclic Refer- (garbage objects that are not referred to from any- ence Counting (TCRC), for object oriented where, and haven’t been deleted) and dangling ref- databases. The algorithm is based on a vari- erences. While these problems are present in tradi- ant of a reference counting algorithm pro- tional programming languages, the effect of a memory posed for functional programming languages leak is limited to individual runs of programs, since The algorithm keeps track of auxiliary refer- all garbage is implicitly collected when the program ence count information to detect and collect terminates. The problem becomes more serious in per- cyclic garbage. The algorithm works correctly sistent object stores, since objects outlive the programs in the presence of concurrently running trans- that create and access them. Automated garbage col- actions, and system failures. It does not ob- lection is essential in an object oriented database to t,ain any long term locks, thereby minimizing protect from the errors mentioned above. In fact, interference with transaction processing. It the Smalltalk binding for the ODMG object database uses recovery subsystem logs to detect pointer standard requires automated garbage collection. updates; thus, existing code need not be re- We model an OODB in the standard way as an ob- writt#en. Finally, it exploit,s schema informa- ject graph, wherein the nodes are the objects and the tion, if available, to reduce costs. We have im- arcs are the references between objects. The graph has plemented the TCRC algorithm and present a persistent root. All objects that are reachable from results of a performance study of the imple- the persistent root or from the transient program state mentation. of an on-going transaction are live; while the rest are garbage. We often call object references as pointers. * Currently at the University of Wisconsin, Madison There have been two approaches to garbage collec- Permission to copy without fee all 01‘ part of this material is tion in object oriented databases: Copying Collector granted provided that the copies are not made or distributed for based [YNY94] and Mark and Sweep based [AFGQ5]. direct commercial advantage, the VLDB copyright notice and The copying collector algorithm traverses the entire ob- the title of the publication and its date appear, and notice is ject graph and copies live objects into a new space; the given that copying is by permission ojthe Very Large Data Base Endowment. To copy otherwise, or to republish, requires a fee entire old space is then reclaimed. In contrast, the and/or special permission jrom the Endowment. Mark and Sweep algorithm marks all live objects by Proceedings of the 23rd VLDB Conference traversing the object graph and then traverses (sweeps) Athens, Greece, 1997 the entire database and deletes all objects that are un- 366 marked. The copying collector algorithm reclusters ob- ing algorithm to handle cyclic data have been proposed jects dynamically; the reclustering can improve locality in the programming language community, including: of reference in some cases, but may destroy program- [Bro85, Bro84, PvEP88]. More recent work in this mer specified clustering resulting in worse performance area includes [Lingo, MWLSO, JL91]. in other cases. The garbage collection algorithms of In this paper, we consider a version of reference [YNY94] as well as [AFG95] handle concurrency con- counting, proposed by Brownbridge [Bro85, Bro84] trol and recovery issues. for functional programming languages, which handles With both the above algorithms, the cost of tra- self referential cycles of garbage. We present an al- versing the entire object graph can be prohibitively gorithm, called Transactional Cyclic Reference Count- expensive for databases larger than the memory size, ing (TCRC), based on Brownbridge’s algorithm, which particularly if there are many cross-page references. is suitable for garbage collection in an OODB. The sa- In the worst case, when the buffer size is a small frac- lient features of the TCRC algorithm are: tion of the database size and objects in a page refer to objects in other pages only, there may be an I/O for l It detects all self referential cycles of garbage un- every pointer in the database. To alleviate this prob- like basic reference counting, and the partitioned lem, earlier work [YNY94, AFG95] has attempted to garbage collection algorithms. divide the database into partitions consisting of a few l It performs a very localized version of mark-and- pages. Each partition stores inter-partition references, sweep to handle cyclic data, with each mark-and- that is references to objects in the partition from ob- sweep likely to access far fewer objects than a jects in other partitions, in a persistent data structure. global mark-and-sweep. Thus it does not have Objects referred to from other partitions are treated to examine the entire database while collecting as if they are reachable from the persistent root, and garbage, except in the worst case. are not garbage collected even if they are not referred to from within the partition. Each partition is garbage l It allows transactions to run concurrently, and collected independent of other partitions; references to does not obtain any long term locks, thereby min- objects in other partitions are not followed. Thus, par- imizing interference with transaction processing. titioning makes the traversal more efficient; the smal- ler the partition, the more efficient the traversal, with l It is integrated with recovery algorithms, and maximum efficiency occurring if the whole partition fits works correctly in spite of system crashes. It also into the buffer space. uses recovery subsystem logs to detect pointer up- Unfortunately, small partitions increase the probab- dates; thus, existing application code need not be ility of self-referential cycles of garbage that cross par- rewritten. tition boundaries; such cyclic garbage is not detected l It exploits schema information, if available, to re- by the partitioned garbage collection algorithms. Pre- duce costs. In particular, if the schema graph is vious work has maintained that such cross cycle struc- acyclic, no cyclic references are possible in the tures will be few, and will “probably” not be a prob- database and TCRC behaves identically to refer- lem. However, simulations by [CWZ94] showed that ence counting. even small increases in database connectivity can pro- duce significant amounts of such garbage. Therefore, A proof of correctness of the TCRC algorithm is it is not clear that partition sizes can be made very presented in [ARS+97]. Designing a cyclic referencing small without either failing to collect large amounts counting algorithm which allows concurrent updates of garbage or employing special (and expensive) tech- and handles system crashes is rather non-trivial, and niques to detect such cyclic garbage. to our knowledge has not been done before; we believe A natural alternative is Reference Counting. Refer- this is one of the central contributions of our paper. ence Counting is based on the idea of keeping a count of A problem often cited against reference counting the number of pointers pointing to each object. When schemes is the overhead of updating reference counts. the reference count of the object becomes zero, it is However, each pointer update can only result in at garbage and eligible for collection. Reference count- most one reference count being updated. This over- ing has the attractive properties of localized and in- head will have only a small impact on performance if, cremental processing. Unfortunately, basic reference as we expect is true in any realistic scenario, pointer counting cannot deal with self-referential cycles of ob- updates are only a small fraction of the overall up- jects; each object could have a positive reference count, dates. For TCRC, moreover, the overhead is offset by yet all the objects in the cycle may be unreachable from the reduced cost of traversals while collecting garbage. the persistent root, and therefore be garbage. However, We have implemented a prototype of the TCRC al- a number of extensions of the basic referencing count- gorithm as well as the partitioned mark and sweep 367 algorithm on a storage manager called Brahmii de- and are deleted. veloped in IIT Bombay. We present a performance However, prior cyclic reference counting algorithms, study of TCRC based on the implementation; the study including Brownbridge’s algorithm, were designed for clearly illustrates the benefits of TCRC. a single user system. They cannot be used in a multi- user environment with concurrent updates to objects, 2 Brownbridge’s Cyclic Reference and do not deal with persistent data and failures. Our Counting Algorithm contributions lie in extending Brownbridge’s algorithm to (a) use logs of updates to detect changes to object Our Transactional Cyclic Reference Counting al- references, (b) to work in an environment with con- gorithm is based on the Cyclic Reference Counting current updates, (c) t,o work on persistent da.ta. in the (CRC) algorithm proposed by Brownbridge [Bro84, presence of system failures and transaction aborts, (d) Bro85], in the context of functional programming lan- handle a batch of updates at a time rather than one up- guages.