[Gc] Re: GC needs to be invoked manually

Martin Wartens martin.wartens at mymail.ch
Mon Aug 29 15:12:34 PDT 2005


> 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
> easy to convert to just use a single boolean mark or bit instead of
> a reference count to save memory and time to do the refcount updates.

Sounds like an interesting idea. So this is going to be some kind of garbage-
collecting smart pointer? Some random thoughts about this: 
In the past I measured the timings of Boehm GC versus new/delete versus 
boost::shared_ptr. It turned out that the gc can create a speedup of up to 2 vs 
new/delete. This, I guess, most likely comes from the bundled deallocations 
that it does, which seems to be very effective for small objects. So maybe you 
should integrate the allocation/deallocation into the ptr.
The penalty for reference counting is usually small, but I have seen situations 
where it really hurts. This happens when there are many long-lived objects with 
short-lived references. Then, the reference counter does a lot of work for 
nothing. And reference counting uses only a small amount of memory, but 
sometimes even that is to much. So if you can do without reference counting, 
that is clearly better.
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. 
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 
seems the Boehm gc uses a lot of voodoo that can't be imitated using only 
language features.

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




More information about the Gc mailing list