What solutions are there for circular references?

Question

When using reference counting, what are possible solutions/techniques to deal with circular references?

The most well-known solution is using weak references, however many articles about the subject imply that there are other methods as well, but keep repeating the weak-referencing example. Which makes me wonder, what are these other methods?

• I am not asking what are alternatives to reference counting, rather what are solutions to circular references when using reference counting.

• This question isn't about any specific problem/implementation/language rather a general question.

Answer 1

Here is a solution I've seen:

Add a method to each object to tell it to release its references to the other objects, say call it Teardown().

Then you have to know who 'owns' each object, and the owner of an object must call Teardown() on it when they're done with it.

If there is a circular reference, say A <-> B, and C owns A, then when C's Teardown() is called, it calls A's Teardown(), which calls Teardown() on B, B then releases its reference to A, A then releases its reference to B (destroying B), and then C releases its reference to A (destroying A).

Answer 2

Y Combinator

I wrote a programming language once in which every object was immutable. As such, an object could only contain pointers to objects that were created earlier. Since all reference pointed backwards in time, there could not possibly be any cyclic references, and reference counting was a perfectly viable way of managing memory.

The question then is, "How do you create self-referencing data structures without circular references?" Well, functional programming has been doing this trick forever using the fixed-point/Y combinator to write recursive functions when you can only refer to previously-written functions. See: https://en.wikipedia.org/wiki/Fixed-point_combinator

That Wikipedia page is complicated, but the concept is really not that complicated. How it works in terms of data structures is like this:

Let's say you want to make a Map<String,Object>, where the values in the map can refer to other values in the map. Well, instead of actually storing those objects, you store functions that generate those objects on-demand given a pointer to the map.

So you might say object = map.get(key), and what this will do is call a private method like _getDefinition(key) that returns this function and calls it:

Object get(String key) {
    var definition = _getDefinition(key);
    return definition == null ? null : definition(this);
}

So the map has a reference to the function that defines the value. This function doesn't need to have a reference to the map, because it will be passed the map as an argument.

When the definition called, it returns a new object that does have a pointer to the map in it somewhere, but the map it self does not have a pointer to this object, so there are no circular references.

Answer 3

Here are some techniques described in Algorithms for Dynamic Memory Management by R. Jones and R. Lins. Both suggest that you can look at the cyclic structures as a whole in some way or another.

Friedman and Wise

The first way is one suggested by Friedman and Wise. It is for handling cyclic references when implementing recursive calls in functional programming languages. They suggest that you can observe the cycle as a single entity with a root object. To do that, you should be able to:

• Create the cyclic structure all at once
• Access the cyclic structure only through a single node - a root, and mark which reference closes the cycle
• If you need to reuse just a part of the cyclic structure, you shouldn't add external references but instead make copies of what you need

That way you should be able to count the structure as a single entity and whenever the RC to the root falls to zero - collect it.

This should be the paper for it if anyone is interested in more details - https://www.academia.edu/49293107/Reference_counting_can_manage_the_circular_invironments_of_mutual_recursion

Bobrow's technique

Here you could have more than one reference to the cyclic structure. We just distinguish between internal and external references for it.

Overall, all allocated objects are assigned by the programmer to a group. And all groups are reference counted. We distinguish between internal and external references for the group and of course - objects can be moved between groups. In this case, intra-group cycles are easily reclaimed whenever there are no more external references to the group. However, inter-group cyclic structures should still be an issue.

If I'm not mistaken, this should be the original paper - https://dl.acm.org/doi/pdf/10.1145/357103.357104

---

I'm in the search for other general purpose alternatives besides those algorithms and using weak pointers.

Answer 4

If you need to store the cyclic data, for a snapShot into a string,

I attach a cyclic boolean, to any object that may be cyclic.

Step 1: When parsing the data to a JSON string, I push any object.is_cyclic that hasn't been used into an array and save the index to the string. (Any used objects are replaced with the existing index).

Step 2: I traverse the array of objects, setting any children.is_cyclic to the specified index, or pushing any new objects to the array. Then parsing the array into a JSON string.

NOTE: By pushing new cyclic objects to the end of the array, will force recursion until all cyclic references are removed..

Step 3: Last I parse both JSON strings into a single String;

Here is a javascript fiddle... https://jsfiddle.net/7uondjhe/5/

function my_json(item) {

var parse_key = 'restore_reference', 
    stringify_key = 'is_cyclic';

var referenced_array = [];


var json_replacer = function(key,value) {

            if(typeof value == 'object' && value[stringify_key]) {
                var index = referenced_array.indexOf(value);

                if(index == -1) {
                    index = referenced_array.length;
                    referenced_array.push(value);
                };

                return {
                    [parse_key]: index
                }
            }
            return value;
}

var json_reviver = function(key, value) {

        if(typeof value == 'object' && value[parse_key] >= 0) {
                return referenced_array[value[parse_key]];
        }
        return value;
}
var unflatten_recursive = function(item, level) {
        if(!level) level = 1;
        for(var key in item) {
            if(!item.hasOwnProperty(key)) continue;
            var value = item[key];

            if(typeof value !== 'object') continue;

            if(level < 2 || !value.hasOwnProperty(parse_key)) {
                unflatten_recursive(value, level+1);
                continue;
            }

            var index = value[parse_key];
            item[key] = referenced_array[index];

        }
};


var flatten_recursive = function(item, level) {
        if(!level) level = 1;
        for(var key in item) {
            if(!item.hasOwnProperty(key)) continue;
            var value = item[key];

            if(typeof value !== 'object') continue;

            if(level < 2 || !value[stringify_key]) {
                flatten_recursive(value, level+1);
                continue;
            }

            var index = referenced_array.indexOf(value);

            if(index == -1) (item[key] = {})[parse_key] = referenced_array.push(value)-1; 
            else (item[key] = {})[parse_key] = index;
        }
};


return {

    clone: function(){ 
        return JSON.parse(JSON.stringify(item,json_replacer),json_reviver)
},

    parse: function() {
            var object_of_json_strings = JSON.parse(item);
            referenced_array = JSON.parse(object_of_json_strings.references);
            unflatten_recursive(referenced_array);
            return JSON.parse(object_of_json_strings.data,json_reviver);
    },

    stringify: function() {
            var data = JSON.stringify(item,json_replacer);
            flatten_recursive(referenced_array);
            return JSON.stringify({
                        data: data,
                        references: JSON.stringify(referenced_array)
                });
    }
}
}

Answer 5

No one has mentioned that there is a whole class of algorithms that collect cycles, not by doing mark and sweep looking for non-collectable data, but only by scanning a smaller set of possibly circular data, detecting cycles in them and collecting them without a full sweep.

To add more detail, one idea for making a set of possible nodes for scanning would be ones whose reference count was decremented but which didn't go to zero on the decrement. Only nodes to which this has happened can be the point at which a loop was cut off from the root set.

Python has a collector that does that, as does PHP.

I'm still trying to get my head around the algorithm because there are advanced versions that claim to be able to do this in parallel without stopping the program...

In any case it's not simple, it requires multiple scans, an extra set of reference counters, and decrementing elements (in the extra counter) in a "trial" to see if the self referential data ends up being collectable.

Some papers: "Down for the Count? Getting Reference Counting Back in the Ring" Rifat Shahriyar, Stephen M. Blackburn and Daniel Frampton http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf "A Unified Theory of Garbage Collection" by David F. Bacon, Perry Cheng and V.T. Rajan http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf

There are lots more topics in reference counting such as exotic ways of reducing or getting rid of interlocked instructions in reference counting. I can think of 3 ways, 2 of which have been written up.

Answer 6

Put things into a hierarchy

Having weak references is one solution. The only other solution I know of is to avoid circular owning references all together. If you have shared pointers to objects, then this means semantically that you own that object in a shared manner. If you use shared pointers only in this way, then you can hardly get cyclic references. It does not occur very often that objects own each other in a cyclic manner, instead objects are usually connected through a hierarchical tree-like structure. This is the case I'll describe next.

Dealing with trees

If you have a tree with objects having a parent-child relationship, then the child does not need an owning reference to its parent, since the parent will outlive the child anyways. Hence a non-owning raw back pointer will do. This also applies to elements pointing to a container in which they are situated. The container should, if possible, use unique pointers or values instead of shared pointers anyways, if possible.

Emulating garbage collection

If you have a bunch of objects that can wildly point to each other and you want to clean up as soon as some objects are not reachable, then you might want to build a container for them and an array of root references in order to do garbage collection manually.

Use unique pointers, raw pointers and values

In the real world I have found that the actual use cases of shared pointers are very limited and they should be avoided in favor of unique pointers, raw pointers, or -- even better -- just value types. Shared pointers are usually used when you have multiple references pointing to a shared variable. Sharing causes friction and contention and should be avoided in the first place, if possible. Unique pointers and non-owning raw pointers and/or values are much easier to reason about. However, sometimes shared pointers are needed. Shared pointers are also used in order to extend the lifetime of an object. This does usually not lead to cyclic references.

Bottom line

Use shared pointers sparingly. Prefer unique pointers and non-owning raw pointers or plain values. Shared pointers indicate shared ownership. Use them in this way. Order your objects in a hierarchy. Child objects or objects on the same level in a hierarchy should not use owning shared references to each other or to their parent, but they should use non-owning raw pointers instead.

Answer 7

i too am looking for a good solution to the circularly reference counted problem.

i was stealing borrowing an API from World of Warcraft dealing with achievements. i was implicitely translating it into interfaces when i realized i had circular references.

Note: You can replace the word achievements with orders if you don't like achievements. But who doesn't like achievements?

There's the achievement itself:

IAchievement = interface(IUnknown)
   function GetName: string;
   function GetDescription: string;
   function GetPoints: Integer;
   function GetCompleted: Boolean;

   function GetCriteriaCount: Integer;
   function GetCriteria(Index: Integer): IAchievementCriteria;
end;

And then there's the list of criteria of the achievement:

IAchievementCriteria = interface(IUnknown)
   function GetDescription: string;
   function GetCompleted: Boolean;
   function GetQuantity: Integer;
   function GetRequiredQuantity: Integer;
end;    

All achievements register themselves with a central IAchievementController:

IAchievementController = interface
{
   procedure RegisterAchievement(Achievement: IAchievement);
   procedure UnregisterAchievement(Achievement: IAchievement);
}

And the controller can then be used to get a list of all the achievements:

IAchievementController = interface
{
   procedure RegisterAchievement(Achievement: IAchievement);
   procedure UnregisterAchievement(Achievement: IAchievement);

   function GetAchievementCount(): Integer;
   function GetAchievement(Index: Integer): IAchievement;
}

The idea was going to be that as something interesting happened, the system would call the IAchievementController and notify them that something interesting happend:

IAchievementController = interface
{
   ...
   procedure Notify(eventType: Integer; gParam: TGUID; nParam: Integer);
}

And when an event happens, the controller will iterate through each child and notify them of the event through their own Notify method:

IAchievement = interface(IUnknown)
   function GetName: string;
   ...

   function GetCriteriaCount: Integer;
   function GetCriteria(Index: Integer): IAchievementCriteria;

   procedure Notify(eventType: Integer; gParam: TGUID; nParam: Integer);
end;

If the Achievement object decides the event is something it would be interested in it will notify its child criteria:

IAchievementCriteria = interface(IUnknown)
   function GetDescription: string;
   ...
   procedure Notify(eventType: Integer; gParam: TGUID; nParam: Integer);
end;    

Up until now the dependancy graph has always been top-down:

 IAchievementController --> IAchievement --> IAchievementCriteria

But what happens when the achievement's criteria have been met? The Criteria object was going to have to notify its parent `Achievement:

 IAchievementController --> IAchievement --> IAchievementCriteria
                                    ^                      |
                                    |                      |
                                    +----------------------+

Meaning that the Criteria will need a reference to its parent; the who are now referencing each other - memory leak.

And when an achievement is finally completed, it is going to have to notify its parent controller, so it can update views:

 IAchievementController --> IAchievement --> IAchievementCriteria
      ^                      |    ^                      |
      |                      |    |                      |                                        
      +----------------------+    +----------------------+

Now the Controller and its child Achievements circularly reference each other - more memory leaks.

i thought that perhaps the Criteria object could instead notify the Controller, removing the reference to its parent. But we still have a circular reference, it just takes longer:

 IAchievementController --> IAchievement --> IAchievementCriteria
      ^                      |                          |
      |                      |                          |                                        
      +<---------------------+                          |
      |                                                 |
      +-------------------------------------------------+

---

The World of Warcraft solution

Now the World of Warcraft api is not object-oriented friendly. But it does solve any circular references:

1. Do not pass references to the Controller. Have a single, global, singleton, Controller class. That way an achievement doesn't have to reference the controller, just use it.

   Cons: Makes testing, and mocking, impossible - because you have to have a known global variable.

2. An achievement doesn't know its list of criteria. If you want the Criteria for an Achievement you ask the Controller for them:

    IAchievementController = interface(IUnknown)
        function GetAchievementCriteriaCount(AchievementGUID: TGUID): Integer;
        function GetAchievementCriteria(Index: Integer): IAchievementCriteria;
    end;
   

   Cons: An Achievement can no longer decide to pass notifications to it's Criteria, because it doesn't have any criteria. You now have to register Criteria with the Controller

3. When a Criteria is completed, it notifies the Controller, who notifies the Achievement:

    IAchievementController-->IAchievement      IAchievementCriteria
         ^                                              |
         |                                              |
         +----------------------------------------------+
   

   Cons: Makes my head hurt.

i'm sure a Teardown method is much more desirable that re-architecting an entire system into a horribly messy API.

But, like you wonder, perhaps there's a better way.

Answer 8

When using reference counting, what are possible solutions/techniques to deal with circular references?

Three solutions:

1. Augment naive reference counting with a cycle detector: counts decremented to non-zero values are considered to be potential sources of cycles and the heap topology around them is searched for cycles.

2. Augment naive reference counting with a conventional garbage collector like mark-sweep.

3. Constrain the language such that its programs can only ever produce acyclic (aka unidirectional) heaps. Erlang and Mathematica do this.

4. Replace references with dictionary lookups and then implement your own garbage collector that can collect cycles.

Answer 9

I have always redesigned to avoid the issue. One of the common cases where this comes up is the parent child relationship where the child needs to know about the parent. There are 2 solutions to this

1. Convert the parent to a service, the parent then does not know about the children and the parent dies when there are no more children or the main program drops the parent reference.

2. If the parent must have access to the children, then have a register method on the parent which accepts a pointer that is not reference counted, such as an object pointer, and a corresponding unregister method. The child will need to call the register and unregister method. When the parent needs to access a child then it type casts the object pointer to the reference counted interface.

Answer 10

I'd like to suggest a slightly different method that occured to me, I don't know if it has any official name:

Objects by themeselves don't have a reference counter. Instead, groups of one or more objects have a single reference counter for the entire group, which defines the lifetime of all the objects in the group.

In a similiar fashion, references share groups with objects, or belong to a null group.

A reference to an object affects the reference count of the (object's) group only if it's (the reference) external to the group.

If two objects form a circular reference, they should be made a part of the same group. If two groups create a circular reference, they should be united into a single group.

Bigger groups allow more reference-freedom, but objects of the group have more potential of staying alive while not needed.

Answer 11

I've looked at the problem a dozen different ways over the years, and the only solution I've found that works every time is to re-architect my solution to not use a circular reference.

Edit:

Can you expand? For example, how would you deal with a parent-child relation when the child needs to know about/access the parent? – OB OB

As I said, the only good solution is to avoid such constructs unless you are using a runtime that can deal with them safely.

That said, if you must have a tree / parent-child data structure where the child knows about the parent, you're going to have to implement your own, manually called teardown sequence (i.e. external to any destructors you might implement) that starts at the root (or at the branch you want to prune) and does a depth-first search of the tree to remove references from the leaves.

It gets complex and cumbersome, so IMO the only solution is to avoid it entirely.

Answer 12

I guess another method, used by garbage collectors, is "mark and sweep":

1. Set a flag in every object instance
2. Traverse the graph of every instance that's reachable, clearing that flag
3. Every remaining instance which still has the flag set is unreachable, even if some of those instances have circular references to each other.

Answer 13

There are couple of ways I know of for walking around this:

The first (and preferred one) is simply extracting the common code into third assembly, and make both references use that one

The second one is adding the reference as "File reference" (dll) instead of "Project reference"

Hope this helps