This document describes the reference counting mechanisms in Apple’s Swift language. I am still unclear about the distinction between unowned and weak but there remains a problem whose only solutions that I know imputes a considerable cost. When a weak reference is passed about it may get to places other than where it arose. When the referenced thing is deallocated what becomes of the weak references use of which would access departed objects?
  1. One scheme forms a linked list of such references so that they can all be found and nullified upon deallocation. Probably the list must be doubly linked so that members can be efficiently removed as when a weak pointer is stored into or deallocated. The cost is tripled, as in prepared Keykos keys.
  2. References can include an ‘allocation count’ which is duplicated in the object. Deallocation increments the count. If a stale reference is used the count will mismatch and the reference is thwarted. Keykos keys to objects on disk take this form dynamically.
  3. Another scheme permanently indirects thru a small permanently allocated small entry on a table of objects. The table entry can be marked as null. Very rare GC's can reclaim table space. Some capability systems use such a table and call it the ‘object table’.
The 1st and 2nd schemes double pointer size. The 3rd is reminiscent of a Mac OS 9 object table scheme which had complexity costs.

Memory technologies (memristor) are on the near horizon where write count limitation which increments and decrements to a reference count would be fatal. The object table would seem required there. Swift is not yet confronted by these.

References to counters is complex in case of multiprogramming. Keykos has untested plans, but there is a cost.

An older note to myself:

An idea for reference counting. My objection to referencing count has been that objects banished to memory that is fast to read and slow to write is that incrementing and decrementing the counters is too expensive.

It now occurs to me that the decision to put something is seldom mutable memory is accompanied with a decision to form a unique pointer to the real new address and next to that pointer keep the counter. All accesses to the object are indirect thru the unique pointer.

Of course this is reminiscent of an old Apple table of pointers thru which you “always go”. The problem is that some subroutines may change the real address as a side effect and any change must invalidate all caches of the real address, for instance on the stack.

To address that we assume that languages do not reify that counter space. Compiler optimizations to bypass counter space are known to the compiler and direct pointers on the stack or other continuations to objects or sub-objects can be found there by stack frame type savvy GC code. All it needs to know is what words in the frame are pointers. This means that any direct pointer into an object must have an offset which is not negative!