From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-10-06 15:43:29
On Monday, Oct 6, 2003, at 14:32 America/Denver, Philippe A. Bouchard
> cppljevans_at_[hidden] wrote:
>> I've just uploaded
>> I was hoping you could provide a similar analysis of memory used for
>> this gc_collector. In particular, sizeof(shared_ptr<T>) is the same
>> the above (as noted by Greg Colvin's post:
>> http://article.gmane.org/gmane.comp.lib.boost.devel/25877 ). This is
>> the size/smart_ptr, but I'm wondering how shifted_ptr compares
>> with shared_ptr w.r.t. each pointee. (see the compare_mem.zip
>> (anal.mem.share_ptr.html) under the Vertices item).
>>> So in fact: by using the default alternative the smart pointer is
>>> going to be resonably fast and destructors are going to be properly
>>> called even for cyclic references. This is perfect.
>> Give us a hint as to how cyclic reference are handled.
> That is a great document, really interesting. If we are talking about
> root_collector I was talking about; then given:
> Group: group of pointees on the heap refering to themselves.
> Root: a smart pointer on the stack refering to a group.
> Indicator: a counter indicating the number of times a group is refered
> to by
> a smart pointer on the stack (let's call it this way).
> template <T>
> class shifted_ptr<T, root_collector>
> T * m_ptr;
> long * m_ind;
> - Every time a shifted_ptr<> on the stack or static data (! heap) is
> handling a new pointee, it will create a new "indicator".
> - Every shifted_ptr<> is refering to an "indicator" so that it can be
> on to new pointees.
> - If a new pointer on the stack is now refering to a new group, the
> indicator is incremented.
> - If a pointer on the stack that was refering to a group on the heap
> destructed, the indicator is decremented.
> - If a pointer on the stack is the last one that was refering to a
> the group will get destructed (cyclisism).
> There is no graph scanning, everything works instantaneously,
> fast and:
> - sizeof("indicator") == sizeof(long)
> - sizeof(shifted_ptr<T, root_collector>) == sizeof(void *) * 2
That is the same size as shared_ptr. So why not put the effort into
a garbage collecting allocator for shared_ptr?
> - only 1 indicator will be created everytime a smart pointer on the
> (or data segment) is handling a new pointee on the heap.
> - the destructors will always be called on time.
> As for determining where the object lives in (heap, stack, data), they
> many alternatives.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk