I've just reworked SPRepr to derive from Inkscape::Refcounted, so it is garbage-collector-aware (I've already done this with NRObject).
What I mean by "gc-aware" is that it is safe to put pointers to garbage-collected objects in them, and that they are managed by the garbage collector. Normally gc-aware objects should derive from Inkscape::GC::Object or Inkscape::GC::FinalizedObject.
GC::Object is the most lightweight of the base classes; it has no overhead, but destructors will not be run when it is collected (not a problem if there are no nontrivial destructors).
GC::FinalizedObject (deriving from GC::Object) runs its destructors before it is collected, but there is additional overhead for tracking the destructors and a C++ vtable.
Inkscape::Refcounted (which derives from FinalizedObject) is the heaviest of the "gc-aware" base classes, as it adds the overhead of an "Anchor" pointer and a refcount. The refcount is initialized to 1.
It's also special among managed classes in that it allows you to safely keep references to Inkscape::Refcounted objects in non-gc-aware classes; all you need to do treat them like normal refcounted objects; increment their refcount with Inkscape::Refcounted::claim(), and decrement it with Inkscape::Refcounted::release().
As a result, an Inkscape::Refcounted will never be collected out from under you so long as its refcount is nonzero.
The intent is that Inkscape::Refcounted will provide an interface between non-gc-aware code (e.g. classes derived from GObject or gtkmm's Glib::Object), and lighter-weight gc-aware objects.
(it's safe to store pointers to gc-managed objects in automatic, global or static variables, as well as function parameters, so this is only a concern for storing pointers in dynamically-allocated objects)
By the way, we can't simply make glib use the boehm allocator, since glib is used to allocate pixmaps, and RGBA pixmaps look like huge arrays of pointers. Maybe we could get away with it, but I think that'd be pushing our luck with a conservative collector.
-mental