VOSS 3.1

Garbage Tips

 
‘Garbage’, in an object-oriented database system, means objects which have become unreachable and are to be removed to reclaim storage space. The garbage collector (’GC’) in VOSS is a ‘Baker’ design, similar in concept to the garbage collector in Smalltalk-80, and which can be run in foreground and/or background modes of which more later.

Unlike the mark-sweep design, which truly is a ‘garbage collector’, the Baker design would be better characterised as a ‘good object preserver’ which copies all reachable objects within a virtual space back and forth from one ’semi-space’ to another, deleting everything left behind on each flip. This has consequences for database design, administration, and the choice of GC settings, to tune for maximum transaction throughput and minimum time offline.

Know which space your objects are in.

In a database design using multiple virtual spaces, the most important thing to know is that when the VOSS GC flips it preserves only those objects in a virtual space which are (indirectly) reachable from the rootDictionary of that virtual space or from the image in which the GC is then running (in the case of uncommitted new objects). In other words, any object in virtual space ‘A’ which is referenced only by an object in virtual space ‘B’, though it will behave normally whilst present, will not be preserved when the GC flips virtual space ‘A’. Or in other words again, reference(s) from object(s) in another virtual space alone are not sufficient to preserve an object from the GC of the virtual space in which it exists. In its systematic copying, the GC does not follow references to objects outside the virtual space which it is scanning.

This situation must be avoided, as after such a flip, those objects would become instances of VOUndefinedObject, and later magically become some arbitrary new object when the id number of that apparently garbage object in space ‘A’ was re-allocated to a new object, having spent some days, weeks or months on space ‘A’s free id list.

The simplest way to keep this right is always to use one of the explicit variants of the message to virtualize an object, preferably on creation, which specify the location explicitly, for example:

  myObject := MyClass newVirtualIn: aVOManager.

The non-specific variants, for example:

  myObject := MyClass newVirtual.

virtualize the new instance in the current virtual space of the current process, i.e. the virtual space which hosts the last object to have received a message in the current process.

Why use multiple virtual spaces?

One reason for distributing a database across multiple virtual spaces may be that some parts of the database are static, whilst others are volatile - subject to frequent update and new object creation - and in this case unnecessary GC processing can be avoided by suitable partitioning of the database, so that the more static virtual space is GC’d less frequently, if at all.

Foreground or Background Garbage Collection?

Foreground GC scans and saves a specified number of reachable objects as an addendum to  each transaction commit, before that transaction’s changes are physically written to disk, to minimise disk activity. The effect, to the user, is that each transaction commit takes longer than it otherwise would, depending on the number of objects it is set to scan.

Background GC runs as one or more separate background process(es), effectively as a dummy user(s) committing null transactions, which each do some GC, as above. Within each image, background GC process(es) (though there is no sensible reason to have more than one in each image) commit their invisible dummy transactions once every user-specified time delay - by default 3000 milliseconds - and scan the user-specified number of objects each time.

The advantage of background GC is that it utilises the time in between application transaction commits, the disadvantage is that it causes more disk flushing activity than foreground GC.

Foreground GC is indicated if the application consists mainly of frequent transactions which are a short time n the preparation before commit (i.e. whilst the application has control); background GC is indicated if transactions are less frequent and/or a long time in the preparation, especially open-ended interactive transactions, when background GC can go on whilst the user is thinking.
Read original blog post