draft proposal for ref counting in D

[Walter Bright]

On 6/25/2013 6:09 PM, Michel Fortin wrote:
 > ## Some general comments
 >
 > While its a start, this is hardly enough for Objective-C. Mostly for legacy 
reasons, most Objective-C methods return autoreleased objects (deferred release 
using an autorelease pool) based on a naming convention. Also, Objective-C 
objects can't be allocated from the D heap, so to avoid cycles we need weak 
pointers. More on Objective-C later.
 >
 > While it's good that a direct call to AddRef/Release is forbidden in @safe 
code, I think it should be forbidden in @system code too. The reason is that if 
the compiler is inserting calls to these automatically and you're also adding 
your own explicitly in the same function, it becomes practically impossible to 
reason about the reference counts, short of looking at the assembly. Instead, I 
think you should create a @noarc attribute for functions: it'll prevent the 
compiler for inserting any of those calls so it becomes the responsibility of 
the author to make those calls (which are then allowed). @noarc would be 
incompatible with @safe, obviously.

It's a good point, but adding such an attribute to the function may be too 
coarse, for one, and may cause composition problems, for another. Maybe just 
disallowing it altogether is the best solution.

 >
 > Finally, that's a nitpick but I wish you'd use function names that fit D 
better, such as opRetain and opRelease. Then you can add a "final void 
opRetain() { AddRef(); }" function to the IUnknown COM interface and we could do 
the same for Objective-C.

Makes sense.

 >
 > ## Objective-C autoreleased objects
 >
 > Objective-C is a special case. In Objective-C we need to know whether the 
returned object of a function is already retained or if it is deferred released 
(autoreleased). This is easily deducted from the naming convention. 
Occasionally, we might need to create autorelease pools too, but that can 
probably stay @system.
 >
 > (Note: all this idea of autoreleased objects might sound silly, but it was a 
great help before ARC, and Objective-C ARC has to be compatible with legacy code 
so it conforms to those conventions.)
 >
 > You can easily implement ARC for COM using an implementation of ARC for 
Objective-C, the reverse is not true because COM does not have this (old but 
still needed) concept of autorelease pools and deferred release where you need 
to know at each function boundary whether returned values (including those 
returned by pointer arguments) whether the object is expected to be retained or not.
 >
 > If I were you Walter, I would just not care about Objective-C idioms while 
implementing this feature at first. It'll have to be special cased anyway. 
Here's how I expect that'll be done:

 From reading over that clang document, O-C arc is far more complex than I'd 
anticipated. I think it is way beyond what we'd want in regular D. It also comes 
with all kinds of pointer and function annotations - something I strongly want 
to avoid.

 >
 > What will need to be done later when adding Objective-C support is to add an 
internal "autoreleasedReturn" flag to a function that'll make codegen call 
"autorelease" in the callee when returning an object and "retain" in the caller 
where it receives an object from a function with that flag. Also, the same flag 
and behaviour is needed for out parameters (to mimick those cases where an 
object is returned by pointer). That flag will then be set automatically 
internally depending on the function name (only for Objective-C member 
functions), and it should be possible to override it explicitly with an 
attribute or a pragma of some sort. This is what Clang is doing, and we must 
match that to allow things to work.

I agree that this complexity should only be in O-C code.

 >
 > Checking for null is redundant in the Objective-C case: that check is done by 
the runtime. That's of minor importance, but it might impact performance and 
should probably special-cased in this case.
 >
 > ## Optimizations
 >
 > With Apple's implementation of reference counting (using global hash tables 
protected by spin locks), it is more efficient to update many counters in one 
operation. The codegen for Objective-C ARC upon assignement to a variable calls 
"objc_storeStrong(id *object, id value)", incrementing and decrementing the two 
counters presumably in one operation (as well as replacing the content of the 
variable pointed by the first argument with the new value).
 >
 > Ideally, the codegen for Objective-C ARC in D would call the same functions 
so we have the same performance. This means that codegen should make a call 
"objc_retain" when first initializing a variable, "objc_storeStrong" when doing 
an assignment, and "objc_release" when destructing a variable.
 >
 > As for returning autoreleased objects, there are two functions to choose from 
depending on whether the object needs to be retained at the same time nor not. 
(In general, the object needs to be retained prior autoreleasing if it comes 
from a variable not part of the function's stack frame.)
 >
 > Here's Clang's documentation for how it implements ARC:
 > http://clang.llvm.org/docs/AutomaticReferenceCounting.html
 >
 > ## Objective-C weak pointers
 >
 > Weak pointers are essential in order to break retain cycles in Objective-C 
where there is no GC. They are implemented with the same kind of function calls 
as strong pointers. Unfortunately, Apple's Objective-C implementation won't sit 
well with D the way it works now.
 >
 > Weak pointers are implemented in Objective-C by registering the address of 
the pointer with the runtime. This means that when a pointer is moved from one 
location to another, the need to be notified of that through a call to 
objc_moveWeak. This breaks one assumption of D that you can move memory at will 
without calling anything.
 >
 > While we could still implement a working weak pointer with a template struct, 
that struct would have to allocate a pointer on the heap (where it is guarantied 
to not move) so it can store the true weak pointer recognized by the runtime. 
I'm not sure that would be acceptable, but at least it would work.
 >
 > ## More on reference counting
 >
 > I feel like I should share some of my thoughts here about a broader use of 
reference counting in D.
 >
 > First, we don't have to assume the reference counter has to be part of the 
object. Apple implements reference counting using global hash tables where the 
key is the address. It works very well.
 >
 > If we added a hash table like this for all memory allocated from the GC, we'd 
just have to find the base address of any memory block to get to its reference 
counter. I know you were designing with only classes in mind, but I want to 
point out that it is possible to reference-count everything the GC allocates if 
we want to.

D would need manual, RC and GC to coexist peacefully.

 >
 > The downside is that every assignment to a pointer anywhere has to call a 
function. While this is some overhead, it is more predictable than overhead from 
a GC scan and would be preferred in some situation (games I guess). Another 
downside is you have an object retained by being present on the stack frame of a 
C function, it'd have to be explicitly retained from elsewhere.

Doesn't this make it impractical to mix vanilla C with D code? An important 
feature of D is this capability, without worrying about a "JNI" style interface. 
As for D switching to a full refcounted GC for everything, I'm very hesitant for 
such a step. For one thing, reading the clang spec on all the various pointer 
and function annotations necessary is very off-putting.


 >
 > As for pointers not pointing to GC memory, the generic addRef/release 
functions can ignore those pointers just like the GC ignores them today when it 
does its scan.
 >
 > Finally, cycles can still be reclaimed by having the GC scan for them. Those 
scans should be less frequent however since most of the memory can be reclaimed 
through reference counting.
 >
 >
 >