In article <hh49qn$vv6$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
Kaz Kylheku wrote:
On 2009-12-25, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
James Kanze wrote:
On Dec 24, 10:11 am, Branimir Maksimovic <bm...@hotmail.com> wrote:
tanix wrote:
In article <hguelj$k4...@news.albasani.net>, Branimir Maksimovic
<bm...@hotmail.com> wrote:
[...]
Memory managment is not a problem. You can implement GC, for
any apllication even in assembler. Reference counting is
simple form of gc and works well in c++ because of RAII.
Reference counting doesn't work in C++, because of cycles. And
reference counting is very, very slow compared to the better
garbage collector algorithms.
Hm, have you ever head cycles? In my long experience I never
had cyclic references...
Reference counting can;t be slow because it does not have
to lock all threads
Reference counting blocks the calling thread on an atomic increment
or decrement operation whenever the reference count must be manipulated.
Hm, it does block nothing, actually it can happen if two or more
threads share same object which is in practice rare case.
And in same time add/release references.
Actually typical scenario is auto_ptr not shared ptr when
one thread passes object to the other.
Reference counting generates bus traffic. Whenever a refcount field is
written, the corresponding cache line is now dirty on the local
processor and must be updated to the other processors.
Reference counting generates much less bus traffic then stopping
program and scanning memory. In order for GC to reach pointers,
it must ensure that every pointer in application
is flushed in memory, which is ....much much worse then
reference counting... Actually scanning memory generates
bus traffic if scan area, is larger than cache, which
is usually case since real world application heap
is usually larger than available cache.
Refcounting forces garbage objects to be visited one by one before they
are reclaimed, in a random order, and possibly more than once! An object
with refcount 42 will in general be visited 42 times before 42
references can be dropped.
42 references , unlikely... If it had million references, we could
be worried, but 42;)
Someone recently remarked in the comp.lang.lisp newsgroup that a
a particular historic Lisp implementation, which used reference counting
rather than real GC, sometimes fell into such a long pause in
processing a dropped reference that frustrated programmers would just
reboot the system!!!
Hm. Lisp? This is shared_ptr we talking about...
See when you drop a refcount on an object and it reaches zero, you are
not done. That object has pointers to other objects, and /their/
references have to be dropped. Refcounting does not eliminate the
fact that a graph is being walked.
You are wrong. shared_ptr's are usually used externally, auto_ptr's are
usually used internally. or simply new in constructor/delete
in destructor.
But reference counting is the dumbest, slowest way of hunting down garbage.
?
Greets
Jeez. I feel jealous. I wish this is the kind of stuff is the kind