develooper Front page | perl.perl6.internals | Postings from February 2001

Re: Garbage collection (was Re: JWZ on s/Java/Perl/)

Thread Previous | Thread Next
Dan Sugalski
February 12, 2001 10:49
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
Message ID:
At 09:49 AM 2/12/2001 -0800, Jan Dubois wrote:
>On Mon, 12 Feb 2001 14:50:44 -0300, "Branden" <>
> >Actually I was thinking something like PMCs ($@%) being copy-GCed and
> >referred objects (new SomeClass) being refcounted. In this case above, every
> >operation would use refcount's, since they're storing objects in PMCs. What
> >wouldn't use refcount is
> >
> >    foreach $i (@a) {
> >        $i++;
> >    }
> >
> >Normally $i would be an alias to an element of @a, that means it would
> >reference the same PMC that one element of @a is referring to. If in this
> >case copy-GC is used, probably the GC wouldn't even be called inside of the
> >loop, and the whole operation would be done without overhead, even of
> >refcounting, even of copy-GC.
>I would help if we kept in mind when reference counts are actually being
>accessed.  Your loop above doesn't use reference counts even in the
>current implementation.  Reference counts come into play when you
>introduce a lexical variable, create a reference to another variable or
>when you do end-of scope cleanup (provided the scope contained lexicals).

Sort of wrong. Refcounts are altered every time a [SAHG]V * is created, 
destroyed, or stuck in an aggregate. That loop doesn't alter refcounts, but 
pretty much every non-aliasing operation you do with them will affect them.

>Also note that incrementing/decrementing the refcount is really cheap:
>The refcount is in the SV itself (no indirection) and you only execute a
>single inc/dec machine instruction for it.

Individual reference count increments are cheap. Lots and lots of 
increments are not cheap. Decrements aren't nearly as cheap as increments, 
since they're all decrement-and-test operations, with a cleanup if the 
decrement brings you to zero.

>Going to partial refcounts does increase the runtime overhead for *all*
>     inc(sv->refcount)
>     if (sv->flags && REFCOUNTED)
>         inc(sv->refcount)
>This is definitely slower for refcounted variables and probably at least
>not faster for non-refcounted ones: I think the bitmask test and
>conditional jump instruction will most likely take as much time as inc()
>takes longer than just a memory fetch.

The only place you need to deal with refcounts, or the fact that a variable 
has been referenced at all, is when a reference is actually taken, 
destroyed, or copied. Generally speaking, this happens rarely in a program. 
Yes, it may mean scope exit for scopes containing references will be more 
expensive, or that dealing with references themselves is slightly more 
expensive.  I don't think that this happens often enough that we'll see a 
performance loss from it, and if we do we can try plan B.

Even if we *do* end up with reference counting as our primary method of 
determining object life (which I don't think we will), deferring and 
coalescing all the destruction will save us some time. I don't think it'll 
come to that, though.

I'll get something more formal put together in the next few days, so we can 
have something solid to work over, rather than the vague notions we're 
chewing on now.


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai                         have teddy bears and even
                                      teddy bears get drunk

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About