Linus with some good observations on garbage collection

Michael Stover michael.r.stover at gmail.com
Fri Apr 22 11:53:28 PDT 2011


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.segura at 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...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110422/1f8dbafb/attachment-0001.html>


More information about the Digitalmars-d mailing list