7 Known Bugs and Inconveniences

7.1 Garbage collection and persistence

With respect to garbage collection and persistence, there are two separate issues to consider, namely the usual in-memory garbage collection and garbage collection of the persistent store on secondary storage. These are considered in turn below.

7.1.1 In-memory garbage collection

The persistent store kernel keeps track of persistent objects loaded into the current process by maintaining a table of references to these objects. This table is shared by all persistent stores in a program execution. As long as a persistent store is open, no objects from that store can thus become garbage, since they are at least referenced from the internal object table. Currently the only way to delete objects from the internal table is to close the store. Thus, to allow in-memory garbage collection of persistent objects, the persistent store in which these objects are saved must be closed.

A side-effect of deleting objects from the object table is is course that the persistence kernel no longer knows that these objects are persistent, and thus semantically these objects turn into in-memory copies of the real persistent objects, now only available on secondary storage.

7.1.2 Secondary storage garbage collection

Currently there is no built-in support for garbage collection of persistent stores. Thus, once saved in a store, an object stays there until the store is deleted, even though the object may no longer be reachable from any persistent root.

7.1.2.1 Secondary storage garbage collection using the OLD persistense implementation

Note, this technique does not work when using the new persistense implementation.

However, for small persistent stores whose objects fit into virtual memory of the computer at once, and that are not referenced from other persistent stores, it is possible to perform a simple garbage collection using the basic operations of the persistentstore pattern. This is illustrated by the PersistentGC.bet demo fragment. PersistentGC simply reads the transitive closures of all persistence roots into memory, deletes the store, and then saves the persistence roots in a new store with the same name as the old store.

Note, however, that the fragments used to generate the objects saved in the store must be linked with the executable performing the collection.

The demo program gc.bet illustrates how to first delete a number of elements from the persistent table generated by largeWrite.bet, and then perform a garbage collection on the store, using PersistentGC.