5 ms·
>RC on its own does not obey this property. It is sufficient in a functional language that lacks haskell's lazy capacity to "tie the knot". Erlang's data struc
by knome 5y ago
>RC on its own does not obey this property.
It is sufficient in a functional language that lacks haskell's lazy capacity to "tie the knot". Erlang's data structures, for example, are fully immutable, and it is not possible to create a cyclic data structure. Since there cannot be a cyclic data structure, reference counting would be sufficient to manage its memory automatically.
It would still suck since it has to constantly write to all objects being referenced, but it would work.
- cmrdporcupine 5y agoThere are RC systems where the counts are held external to the objects, which can be a bit more cache friendly.
- Kranar 5y agoYou want the opposite behavior in order to be cache friendly, an RC system where the counts are stored next to the object.
- cmrdporcupine 5y agoNot necessarily. The issue is that releasing a reference at the top of a tree of objects has the potential to walk a large graph of objects (doing downcounts at each) that are not in cache, causing some thrash. In an ideal world and in a program running with a not-huge # of objects you could keep the entire basket of reference counts in L1 cache, separate from the objects. Then decrements would be potentially cheap. A bit utopian though.