[Fwd: A couple garbage collector questions]

[Daniel Berlin]

> OTOH, if the program *isn't* going to use the object right away, e.g. if
> object A hands object B a referece to object C so that A can call C at a
> later time, you're prefetching for no purpose.

Except, A had to store the object somewhere, and thus, used it.
Even if it's a simple pointer assignment, A is still storing the object
(or rather, a pointer to it) somewhere so it can all it later, and thus,
you didn't prefetch for no  purpose.
 >
> BTW, there's an algorithm for one-bit reference counts that puts the bit
> in the object pointer.  That is, if the pointer has the lowest-order bit
> set, and you delete that reference, you know it's safe to delete the
> memory it points to (assuming objects are aligned on even addresses).
> There are some complications, of course, such as temporary references
> that would "stick" the count permanently to more than two, requiring
> either a second bit or an "ought to be two" cache.
>
> > Of course that's just random speculation, but isn't random
> > speculation is what memory management arguments are all about?
>
> The ones that are a subset of optimization arguments, yes.
>
> To haul the thread back toward the original topic, the real argument
> against refcounting is its inability to collect cycles without
> programmer intervention.  Some applications and languages are guaranteed
> not to create cycles ... but an interpreter for a general
> object-oriented language isn't one of them
Then it's a good thing we have  GC specifically made to handle cycles (and
only cycles) running by default, isn't it?

>
> --
> Frank Mitchell (frankm at bayarea.net)
>
> Ridiculous Lucky Captain Rabbit King!  Lucky Captain Rabbit King
> Nuggets are only for the youth!
> -- Powerpuff Girls, "Jewel of the Aisle"
> --
> http://mail.python.org/mailman/listinfo/python-list
>