Also add to it that in many cases you're dealing with a threaded environment, so those refcounts have to be locked (either via mutexes, or more commonly just atomic) operations which are far more expensive than non-atomic. More so when there's actual contention for the refcounted resource.
On 4/22/2011 11:53 AM, Michael Stover wrote: > This sort of reference count with cyclic dependency detector is how a lot of > scripting languages do it, or did it in the > past. The problem was that lazy generational GCs are believed to have better > throughput in general. > > I'd like to say "were proved" rather than "are believed", but I don't > actually know where to go for such evidence. > However, I do believe many scripting languages, such as python, eventually > ditched the reference counting technique for > generational, and Java has very fast GC, so I am inclined to believe those > real-life solutions than Linus. > > Mike > > On Fri, Apr 22, 2011 at 2:32 PM, Alvaro <alvaro.seg...@gmail.com > <mailto:alvaro.seg...@gmail.com>> wrote: > > El 22/04/2011 19:36, Walter Bright escribió: > > http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html > > > I've always been surprised when discussions usually just bring garbage > collection as the only alternative to > explicit manual memory management. I imagined it as a garbage truck that > has its own schedule and may let a lot of > trash pile up before passing by. I always naively thought, why not just > free immediately when an object gets no > references? > > Not an expert, so there may be reasons I don't see, but now that Linus > says somethnig along the lines, I'll ask. Why > not? Isn't it much easier to do refcount++ and refcount--, and if > refcount==0 immediately "free()"? Memory will be > available to other needs faster, no need for an additional thread, or a > lot of memory consumed before the advanced > garbage truck decides to come in, or slight pauses when collecting trash > (maybe only in old implementations), and > the implementation is much simpler... > > OK, I knew about that "cyclic references" problem. But Linus doesn't seem > to see a big problem and solutions can be > found with care... > >