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.
