More radical ideas about gc and reference counting

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Sun May 11 01:29:13 PDT 2014


On 5/10/2014 11:27 PM, Manu via Digitalmars-d wrote:
>> Because if this was an easy problem, it would have been solved. In
>> particular, if the ARC overhead was easily removed by simple compiler
>> enhancements, why hasn't ARC taken the world by storm? It's not like ARC was
>> invented yesterday.
>
> And as far as I can tell, it has, at least in this
> (native/compiled/systems) space. O-C, C++/CX, Rust... where are the
> counter-examples?

Again, O-C and C++/CX ARC are not memory safe because in order to make it 
perform they provide unsafe escapes from it. Neither even attempts pervasive ARC.

Rust is simply not an example of proven technology.

We cannot even discuss this if we cannot agree on basic, objective facts.

 > It's **workable**.

Nobody has demonstrated that pervasive ARC is both performant and memory safe.

Have you ever written some code using RC in O-C or C++/CX, and disassembled it 
to see what it looks like? Do you realize that every decrement must happen 
inside an exception handler? Now imagine that for all code that deals with pointers?

------------- A Comment on Rust ------------------

This is based on my very incomplete knowledge of Rust, i.e. just reading a few 
online documents on it. If I'm wrong, please correct me.

Rust's designers apparently are well aware of the performance cost of pervasive 
ARC. Hence, they've added the notion of a "borrowed" pointer, which is an escape 
from ARC. The borrowed pointer is made memory safe by:

1. Introducing restrictions on what can be done with a borrowed pointer so the 
compiler can determine its lifetime. I do not know the extent of these restrictions.

2. Introducing an annotation to distinguish a borrowed pointer from an ARC 
pointer. If you don't use the annotation, you get pervasive ARC with all the 
poor performance that entails.

Implicit in borrowed pointers is Rust did not solve the problem of having the 
compiler eliminate unnecessary inc/dec.


My experience with pointer annotations to improve performance is pretty 
compelling - almost nobody adds those annotations. They get their code to work 
with the default, and never get around to annotating it. This, of course, 
provided me with a large opportunity to kick ass in the performance dept. 
because I would use them, but that didn't help when I had to use other peoples' 
code.

People who have added annotations to Java have seen the same result. They can't 
get regular programmers to use them.

The annotations have their downsides even if you make the effort to use them. 
Since they are a different type from ARC pointers, you cannot have a data 
structure, say a tree, that contains both (without having a tag to say which one 
it is). They do not mix. A function taking one type of pointer cannot be called 
with the other type.

Worse, these effects are transitive, making a function hierarchy rather inflexible.

Are these valid concerns with Rust? I haven't written any Rust code, and I 
haven't heard of a whole lot of Rust code being written. So I don't know. We'll see.


More information about the Digitalmars-d mailing list