[boost] Re: Re: Garbage Collection, Reference Count or Ownership?

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2003-10-05 13:55:30

Douglas Gregor wrote:
> On Sunday 05 October 2003 10:03 am, Philippe A. Bouchard wrote:
>> Let's discuss the "ownership" paradigm:
>>
>> + perfect solution for 1d / 2d / nth d containers, ropes, neural
>> networks, etc.;
>> + is able to play the role of an auto_ptr<> and a weak_ptr<> at the
>> same time;
>> - it is possible to create dangling smart pointers in this case
>> (dangling "weak_ptr<>s");
>> - cannot be easily casted to other pointee types.
>
> I don't believe I know the ownership paradigm; have a reference
> handy? And, of course, that last bit worries me greatly: what kind of
> casting restrictions are we talking about?
>
>>>   1) Do you really need BOOST_GC_DEACTIVATE, if could users just
>>> instead switch over to something like shared_ptr if they really
>>> don't want to use GC? There's no need to allow (or require users to
>>> understand) customization when alernatives already exist.
>>
>> If someone wrote his program with shifted_ptr and suddenly decides to
>> accelerate his program he could simply define this macro, recompile
>> & tada! it works like a normal reference count smart pointer &
>> becomes faster.
>
> Garbage collection can be faster than reference counting, but it all
> depends on usage patterns. For instance, my GC-needing application
> has a phase where it allocates a ton of memory, much of which won't
> be needed later. The next phase runs over the internal representation
> many times (typical compiler/static analyzer behavior).
> Reference-counting would be a killer here, because in the second
> phase we incur all of the overhead of reference counting but get
> little benefit from it, because memory isn't being
> allocated/deallocated much.
>
> I don't know where you want to take shifted_ptr, but I'm of the
> opinion that it should do one thing (well). Macros aren't the place
> to support major shifts in program behavior. If the user wants to be
> able to switch between different smart pointers, she can use typedefs
> or policy-based pointers that allow such things.

If I disable threads and I am using non-polymorphic types, the following
code will be added each time an object is shared (compiled using gcc 3.2.3):
    0x8048da8 <main+360>:   test   %eax,%eax
    0x8048daa <main+362>:   mov    %eax,0xffffffd8(%ebp)
    0x8048dad <main+365>:   movl   $0x8,0xffffffa8(%ebp)
    0x8048db4 <main+372>:   je     0x8048dbc <main+380>
    0x8048db6 <main+374>:   incl   0xfffffff8(%eax)

Accessing the object is a single machine instruction so it is true it
depends what you are doing and the required time to allocate is no more than
a pure garbage collector.  But at this level the resulting overalls could be
negligeable...

So what I am earing right now is that shared_ptr / weak_ptr can replace the
ownership alternative of shifted_ptr (as Larry have mentionned).  Thanks for
your help.

Philippe

BTW: NRC is just across the river ;)