CSpace Garbage Collector

A CSpace employs a "stop the world" mark and sweep tracing garbage collector (GC) to determine the lifetime of heap allocated objects that implement IObject.

The chief advantages of a GC are:

A component architecture raises some challenging memory management problems if reference counting is used - particularly if it supports some form of orthogonal persistence. The issue is that changes to persistent reference counters represents a significant overhead if it means objects often need to be written back to disk just because their reference count has changed.

Object deletion is performed during the sweep phase without a lock on the CSpace.

Tracing GC is not easy to implement without compiler support. To keep things simple we make the following assumptions

In the future it may be worthwhile looking into a generational garbage collector algorithm.

Objects in the CSpace must implement the VisitObjects() function to visit all outgoing pointers, to allow the GC trace to be performed.

Rate at which garbage collections are performed

A CSpace defines a rate at which garbage collections are performed, in terms of the period in milliseconds between garbage collections.

Refer to the methods GetMilliSecsPerGc() and SetMilliSecsPerGc() defined on CSpace.

gcroot

A gcroot<T*> represents a smart pointer that retains shared ownership of a heap allocated IObject of type T which is registered in a CSpace.

This provides a basis to visit objects referenced by variables on the frame (since this isn't done automatically by the C++ compiler).

Object eviction


$function+ void SetTouched(ptr<IObject> obj)

Calling thread needs shared read or exclusive lock on the CSpace When a weak referenced ptr is accessed by a thread during a shared read lock we set its last touched time. This serves two purposes:-


$function+ void SetEvictableObjectSizeInBytes(ptr<const IObject> obj, ssize_t sizeInBytes)

Set the size of the given evictable object to be assumed to determine how many objects should be evicted.