GC, the simple solution

Sean Kelly sean at f4.ca
Mon Jun 5 09:17:41 PDT 2006


For what it's worth, incremental GC is similar to refcounting in that 
the cost is distributed across pointer use to avoid the need for a 
costly mark/sweep phase.  I've even seen hard-realtime incremental GC 
implementations, so it's a long-term solution worth considering.  That 
said, I would like to be able to create some sort of smart pointer in D 
for tracking valuable resources, so it's good to hear that Walter is 
considering this as well.

Frank Benoit wrote:
 >
>> 3) in a multithreaded app, the incs and decs must be synchronized
> 
> Isn't a atomic inc/dec enough? (Don't know anything about the
> performance of the asm "lock" instruction)

Depending on the platform and the synch. requirement, a "lock" type 
instruction may be necessary.  It typically is for non-x86 platforms, 
but I think you could get away without using one in some cases on x86. 
The best place to check for optimizations would be the Boost shared_ptr 
code.  IIRC they don't use the Interlocked calls but there are spin 
locks in some places.

The cost of a "lock" instruction is variable based on the hardware, 
number of CPUs, whether the cache line is shared, etc, but the most 
reliable estimate I've seen averages locked ops at around 70ns.

>> 9) Ref counting does not eliminated latency problems, it just reduces them.
> 
> Where do you mean is the latency with RC? The collecting work is done in
> the smallest pieces all the time. Only the allocation of new memory
> needs an unbound time to complete. But it does not need to stop all
> other threads. e.g. hardware interrupts don't need to be disabled.

I've seen analyses that suggested reference counting is actually slower 
than mark/sweep when measured over the run of the program.  The 
advantage is the avoidance of the unbounded mark/sweep phase, with far 
more expensive pointer modifications instead.  As above, I'd almost 
rather see incremental GC support in D (it typically requires additional 
ode generation on pointer modifications, and may be tricky to sort out 
for C routines like memset).


Sean



More information about the Digitalmars-d mailing list