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

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

Dan Sugalski
February 9, 2001 10:26
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
Message ID:
At 04:09 PM 2/9/2001 -0200, Branden wrote:
>Dan Sugalski wrote:
> > At 12:06 PM 2/9/2001 -0500, Ken Fox wrote:
> > >  2. Work proportional to live data, not total data. This is hard to
> > >     believe for a C programmer, but good garbage collectors don't have
> > >     to "free" every allocation -- they just have to preserve the live,
> > >     or reachable, data. Some researchers have estimated that 90% or
> > >     more of all allocated data dies (becomes unreachable) before the
> > >     next collection. A ref count system has to work on every object,
> > >     but smarter collectors only work on 10% of the objects.
> >
> > As is this. (Perl can generate a lot of garbage if you're messing around
> > with strings and arrays a lot)
> >
>Let me see if I got that right. If I change the way some objects are used so
>that I tend to create other objects instead of reusing the old ones, I'm
>actually not degrading GC performance, since its work is proportional to
>live data. Right?

Correct. Whether reuse is a win overall is a separate question. Generally 
not allocating memory is faster than allocating memory, so reuse may mean 
you don't make a trip to the memory allocator at all. (Or fewer trips, at 
least, as perl's likely to do so for you a few times anyway)

>This increases memory usage, though, right? Would this
>cause some thrashing if the excessive memory usage causes degrading to
>virtual memory? (I guess not, since live data would probably be accessed,
>and dead data would probably be discarded somehow before going to virtual
>memory, right?).

It depends on whether the old structures are really unused. If they are, 
one of the GC passes will reclaim the space they're taking. Whether this 
happens before you start swapping's a good question, and that depends on 
your application. Most perl programs won't swap regardless, so it's not a 
big deal most of the time. If your program is large enough to swap, then 
it's time to take rather drastic measures, given how expensive swapping is. 
(It's safe to assume that if perl 6's garbage collector causes otherwise 
small programs to swap then it's busted and needs fixing)

>What are actually the consequences of generating more or less garbage by
>reusing/not reusing structures, under this advanced GC model?

The less memory you chew through the faster your code will probably be (or 
at least you'll have less overhead). Reuse is generally faster and less 
resource-intensive than recycling. What's true for tin cans is true for memory.

> > Finally, all you really need to do is read the last day or so of p5p where
> > Alan's trying to plug a batch of perl memory leaks to see how well the
> > refcount scheme seems to be working now...
>Yeah, I know that... But I actually think this is because Perl 5's
>implementation of refcounting is quite messy, specially when weakrefs are in
>the game.

Almost all refcounting schemes are messy. That's one of its problems. A 
mark and sweep GC system tends to be less prone to leaks because of program 
bugs, and when it *does* leak, the leaks tend to be large. Plus the code to 
do the GC work is very localized, which tends not to be the case in 
refcounting schemes.

Going to a more advanced garbage collection scheme certainly isn't a 
universal panacea--mark and sweep in perl 6 will *not* bring about world 
peace or anything. It will (hopefully) make our lives easier, though.


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai                         have teddy bears and even
                                      teddy bears get drunk Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About