Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Peter Dimov
Date : Wed Apr 13 2005 04:41 pm

Joe Seigh wrote:

> The deferred reference counting mentioned by Andrei seems to be a
> different scheme.  I think there's a way to solve most of the problems
> here. I'll just add it to my list of things I don't have time to do.

Deferred reference counting, as most of the research, is a "Java-centric" 
scheme to deal with non-essential count updates.

"Java-centric" in the sense that its primary target is a fully collected 
language.

The problem with counting collectors is that these languages generate lots 
of count updates each time a reference is copied or "destroyed".

This is much, much less of a problem in C++, where most local references to 
counted objects are ordinary C++ references or pointers and incur no 
overhead.

I don't believe that C++ code can benefit from a traditional deferred 
counting scheme (which avoids counting the stack and the registers and only 
counts heap-allocated references.)

Your local_ptr can possibly benefit from a deferring the counting somewhat, 
but I'm not sure whether it will be worth doing.

Weighted reference counting is another interesting algorithm (on paper). I 
think that it is also not worth doing. The idea there is to keep a local 
count (weight) in each pointer. The pointer starts with 65536 (say) and on 
each copy the weight is shared between the source and the copy. When a 
pointer is destroyed its weight is subtracted from the reference count (its 
initial value is also 65536).

The reason I believe that this scheme is not a gain is that it eliminates 
count increments at the expense of an additional integer in every pointer. 
But count increments are "naked" and in the uncontended case are almost as 
fast as ordinary increments; and the additional size increase in every 
pointer will likely decrease the overall performance of the application. 
(The problem with the copy mutating the source aside for a moment.)

> Actually, I have time, just not time to do pointless things.  I mean, just
> how many more GC schemes do *I* need?

From a C++ viewpoint, I don't believe that you need anything else beyond 
(atomic|shared)_ptr-style counting and hazard pointers. But of course I may 
be wrong. ;-)

.