Ruling out arbitrary cost copy construction?

Michel Fortin michel.fortin at michelf.com
Thu Nov 4 15:16:18 PDT 2010


On 2010-11-04 16:09:26 -0400, "Steven Schveighoffer" 
<schveiguy at yahoo.com> said:

> I just was saying that I prefer solutions where we don't bend the 
> entire  language to cater to reference counting, if we can help it.  
> I'd rather  bend the reference counting implementation to fit the 
> language.  Something  in the middle might be good too.

I just want to drop a note at this. I know it's not exactly the same 
issue, but...

If you've read my plans for D/Objective-C, you'll have seen there's 
automatic reference counting for Objective-C objects on the list. 
There's obviously no plan to implement that for other things than 
Objective-C objects in that document, but once it's implemented for one 
type it'll trivial to allow it for other types.

I've thought throughly about the issue before choosing that direction. 
There are two reasons to implement it in the compiler: easy of use and 
efficiency of the generated code.

Cocoa traditionally has used explicit calls to retain/release (with 
some help from autorelease). This is tedious and error-prone and looks 
out of place in D. The D way would be to create a ref-counting struct 
that wraps Objective-C objects and calls retain/release for you. But 
the problem with that is you'd have to use this struct for each and 
every Objective-C object reference and never forget to use it. We could 
make the compiler forbid not wrapping Objective-C objects in this 
struct, but at this point, why not make the compiler wrap the reference 
in that struct transparently for you?

And if it comes to this, it's probably easier to just skip that 
struct-wrapping scheme entirely and just issue calls to the relevant 
function upon assignment and destruction of Objective-C object 
reference. And this will probably open the door to optimization 
opportunities. Changing an atomic reference count is expensive, but by 
noting that any paired call to retain and release on the same object 
has no effect you can avoid a lot of these calls. How many can be 
avoided? Well, in theory, if the reference count when the object enters 
the function is the same as the reference count when the object leaves 
the function's code, then you don't have to touch the reference counter 
at all. Any function that doesn't leak an object received as an 
argument doesn't have to touch the reference count. That's a lot of 
functions!

So in the end, I think that if reference-counting is going to be used, 
even just moderately, it'd better be in the compiler for efficiency 
reasons. That's only an advantage if you use atomic reference counting, 
but it's the kind of thing that prevent ridiculous "optimizations" like 
making function parameters 'ref' just to avoid touching the reference 
counter... see:
<http://stackoverflow.com/questions/2502394/the-cost-of-passing-by-shared-ptr>

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d mailing list