draft proposal for ref counting in D

[Walter Bright]

On 6/26/2013 4:15 AM, Michel Fortin wrote:
 > Well, it's mostly required to write runtime support functions. The attribute 
could be more obscure so people are less tempted to use it, but if you're going 
to implement the ref-counting code you'll need that.

I know the temptation is strong to create more attributes as an easy solution, 
but I'd really like to try hard to find other ways.

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

 > The problem is how to make the three of those use the same codegen?
 >
 > - Druntime could have a flag to disable/enable refcounting. It'd make the 
retain/release functions no-ops, but it'd not prevent the GC from reclaiming 
memory as it does today.
 > - Druntime could have a flag to disable/enable garbage collection (it already 
has). That'd prevent cycles from being collected, but you could use weak 
pointers to work around that or request a collection manually at the appropriate 
time.
 > - A @noarc (or similar) attribute at the function level could be used to 
prevent the compiler from generating function calls on pointer assignments. You 
could make a whole module @noarc if you want by adding "@noarc:" at the top.
 >
 > Here's the annoying thing: @noarc is totally safe if reference counting is 
disabled and we rely entirely on the GC. @noarc is unsafe when reference 
counting is enabled.

I don't really understand your point. My proposal enables manual, RC and GC to 
coexist peacefully. The GC wouldn't even know about RC.


 >
 >>> 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.
 > It's not very different than with the GC today.
 >
 > If you call a C function by giving it a ref-counted pointer argument, that 
memory block is guarantied to live at least for that call's lifetime (because it 
is retained by the caller). So simple calls to C functions are not a problem.
 >
 > If the C function puts that pointer elsewhere you'll need to retain it some 
other way, but you have to do this with the GC too. If you're implementing a 
callback called from C you need to care about what you return because the 
caller's C code won't retain it, while with the GC you could manage if C code 
did not store that pointer outside of the stack.
 >
 > I think that's all you have to worry about.

D (like C and C++) loves to manipulate pointers. Having to call a function every 
time this is done would be a disaster. It means that people would be motivated 
to drop down to C to do the fast code, and we might as well throw in the towel.



 >> 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.
 > Don't let Clang intimidate you. The Clang spec is about four to five time 
more complicated than needed because of autoreleased objects and because it 
supports weak pointers. Weak pointers can be implemented as a struct templates 
(as long as we have @noarc). And all those annotations are for special cases, 
when you need to break the rules. You don't use them when doing normal 
programming, well except for __weak.
 >

Ok.