[Gc] Re: GC needs to be invoked manually

Larry Evans cppljevans at cox-internet.com
Tue Aug 30 03:16:37 PDT 2005


On 08/29/2005 05:12 PM, Martin Wartens wrote:
>>http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-
> 
> sandbox/libs/policy_ptr/test/wartens_sparse_matrix_test.cpp?rev=1.1&view=auto
> 
>>uses reference counting, but that's just one gc policy.  It's fairly
[snip]
> Sounds like an interesting idea. So this is going to be some kind of garbage-
> collecting smart pointer?
Yes.
[snip]
> should integrate the allocation/deallocation into the ptr.
Well, I've thought about substituting the pointer descriptor
( GC_descr) method described here:

   http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc_typedh.txt

with the method used in the policy_ptr code.  This method is a
modification of [detl92]:

   http://www.cs.kent.ac.uk/people/staff/rej/gcbib/gcbibD.html

which finds pointers in containers as well. The fields_visitor
library implements this method (actually a generalization of the
melthod since it can be applied to any field type, not just
smart_ptrs):

http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/fields_visitor/

If fields_visitor replaced GC_descr, then, of course, the problems with
refcounts would disappear since the resulting code, except for the
method for finding pointers, would be boehmgc.
[snip]
> If I remember right, there exists an exotic problem with cycle collection, when 
> the destructor of an collected object tries to follow pointers (which may be 
> already dead at this time). I don't recollect the details, but it could be a 
> potential headache. 

I think I know what you're refering to.  The solution imposed by the
policy_ptr code is to 1st traverse the pointer graph determining
any cycles of objects to be collected, and then breaking the cycle
(by simply nulling the pointer which closes the cycle) at some
arbitrary point.  It's maybe not what the programmer of the
pointer graph intended, but he obviously did not intend to have
a cycle either, because otherwise he would have used a weak_ptr
to close the cycle.

> One fundamental problem of smart ptrs seems to be that they don't see 
> references to an object, while the Boehm gc can handle both references and 
> pointers to an object. I don't know if there are more problems like that. It 

Yep.  I don't know a work-around for that, but I'm guessing the boost
shared_ptr people have considered that and haven't been too bothered by
it.

[snip]

> Anyway, the policy_ptrs look like an interesting project, keep on going! 

Thanks.  I'm now stuck on learning how to xml document fields_visitor :(

> Best, Martin

Regards, Larry.



More information about the Gc mailing list