More radical ideas about gc and reference counting

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Sun May 11 08:54:48 PDT 2014


On 05/11/2014 10:29 AM, Walter Bright wrote:
> ...
>
> ------------- 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.
> ...

Well, region-based memory management is not new, and Rust's approach is 
natural, even more so when given some background.

Have you ever read up on type systems? Eg:

http://www.cis.upenn.edu/~bcpierce/tapl/
http://www.cis.upenn.edu/~bcpierce/attapl/

> 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.

It is not an escape from ARC per se. It is a way to write type safe code 
which is not dependent on the allocation strategy of the processed data. 
(One can e.g. safely borrow mutable data as immutable and the type 
system ensures that during the time of the borrow, the data does not 
mutate.)

> 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.
> ...

The type system tracks lifetimes across function and data structure 
boundaries. The main restriction is that such a pointer cannot be 
escaped. (But borrowed pointers may still be stored in data structures.)

> 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.
> ...

No, this is completely inaccurate: Both choices are explicit, and 
reference counting is just one of the possible memory management 
schemes. (Hence borrowed pointers are used unless there is a reason not to.)

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

Avoiding inc/dec is not what justifies borrowed pointers.

>
> 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.

The 'default' way to pass by reference is by borrowed pointer.

> ...
> They do not mix. A function taking one type of
> pointer cannot be called with the other type.
> ...

A function taking a borrowed pointer can be called with a reference 
counted pointer. Abstracting over allocation strategy is the point of 
borrowing.

> Worse, these effects are transitive, making a function hierarchy rather
> inflexible.
>
> Are these valid concerns with Rust?

I don't think they are.



More information about the Digitalmars-d mailing list