Rust moving away from GC into reference counting

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Jun 3 08:59:44 PDT 2013


On Mon, Jun 03, 2013 at 04:33:10PM +0200, Adam D. Ruppe wrote:
> On Monday, 3 June 2013 at 14:20:06 UTC, Dicebot wrote:
> >I don't see how struct with a disabled copy constructor is
> >relevant to owned pointers.
> 
> My thought is then you can control access to the inner pointer
> better that way. You couldn't even pass this struct to a function
> without calling some kind of method, which could return a different
> type to indicate that it is a lent pointer.

This is an old idea. It's the same as C++'s auto_ptr, and the same as an
old idea I independently came up with many years ago. Basically, you
have two kinds of pointers: a reference pointer and an owner pointer. An
owner pointer can be freely copied into a reference pointer, but never
the other way around. An owner pointer is unique, so it has destructive
copy semantics (passing it into a function invalidates it in the
caller's scope, for example -- if a function doesn't need ownership of
the passed object, it should take a reference argument, to which an
owner pointer implicitly converts). When it goes out of scope, it's
freed. Reference pointers are never freed.

Of course, this scheme doesn't correctly deal with dangling reference
pointers, but in a manual memory management system, you have to deal
with that manually anyway, so it doesn't really matter. Distinguishing
between these two kinds of pointers for the most part eliminates a lot
of pointer-related bugs.

For the most part, this scheme is sufficient to handle a majority of
pointer uses. The remaining cases involve multiple references to objects
with no clear ownership designation or lifetime.  IME, this is
relatively confined to specific areas of usage, for which the GC is a
better memory management scheme anyway.


> It also wouldn't need to be reference counted, since the refcount is
> always going to be 1 because copying it is impossible.

One should always be aware that there's a rough hierarchy of memory
management schemes:

- direct malloc/free: maximum control, most error-prone
- auto_ptr (the above scheme): less error-prone
- reference counting: more convenient
- GC: very little control, least error-prone

The further down you go, the less you have control over the memory
management process, but also the more convenient it is to write code.
The further up you go, the more control you have, but also the harder it
is to write correct code (and the more error-prone it is).

Given D's design of correctness-first, it would seem that GC by default
is the correct choice. But it should definitely also allow moving up the
hierarchy for applications that require finer control over memory
management. Currently D allows this in theory, but in practice, much of
Phobos assumes the GC, which greatly reduces its usefulness in such
cases.


> >Most similar thing D has is "scope" qualifier concept (and that is
> >why I do want it so hard :)) - hard guarantee that no pointer to
> >your data will live longer than data itself. All normal pointers
> >become managed pointers in that sense.
> 
> Yes, I'm just trying to do what we can with the language today.

auto_ptr can be easily implemented with the language today. It's more a
question of Phobos / certain language constructs *using* it.


T

-- 
Some ideas are so stupid that only intellectuals could believe them. -- George Orwell


More information about the Digitalmars-d mailing list