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.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
