A couple garbage collector questions

[Steve Holden]

"David Bolen" <db3l at fitlinxx.com> wrote in message
news:ulmpeoewi.fsf at ctwd0143.fitlinxx.com...
> Skip Montanaro <skip at pobox.com> writes:
>
> >     >>> Reference-counting exacts very heavy performance costs, no
matter
> >     >>> what you back it up with.
> >
> >     Hannah> Correct. *Except* if the compiler does heavy optimization of
> >     Hannah> reference count updates (i.e. if you can prove that some
basic
> >     Hannah> block just increases the RC, later decreases it, having a
net
> >     Hannah> effect of +- 0, you can drop both RC updates, and so on).
> >
> > This is unlikely to happen in practice.  A basic block consists of a
> > straightline piece of code containing no branches.  There's no reason to
> > increment a reference count and decrement it within the same basic
block,
> > since the object's reference count can't be decremented to zero by some
> > other piece of code.
>
> Not only that, but the basic block has to be atomic in a
> multi-threaded environment.  Otherwise, some other thread may gain
> control and release the last reference to an object that is being used
> within the "basic block" but wasn't marked as such, and the object may
> be reclaimed before the original block gets control again.
>
Unless, of course, you set a lock or otherwise ensure mutual exclusion.
Which is, I believe, where we came in, the original enquirer wondering
whether reference count maintenance wasn't too heavyweight.

Perhaps the salient point is that something as complex as a language
interpreter can't afford to make too many assumptions about the environment,
since the universe will almost always prove simplistic assumptions wrong.
This is not a good way to reduce one's support load ;-)

regards
 Steve