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