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

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

Ken Fox
February 9, 2001 13:49
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
Message ID:
Dan Sugalski wrote:
> At 04:09 PM 2/9/2001 -0200, Branden wrote:
> > 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.

It's totally dependent upon hardware. From a software big-O type of
analysis, creating new objects is never slower than reusing objects.

The problems come about if (a) memory is low and the OS decides to
page without telling the application to prepare for paging or (b) if all
memory isn't the same speed, e.g. caches are faster than main memory.

> > This increases memory usage, though, right? Would this
> > cause some thrashing if the excessive memory usage causes degrading to
> > virtual memory? ...
> 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.

It also depends on locality of reference. Semi-space-based collectors
are not bad at preserving locality -- mark-sweep and malloc-like allocators
are terrible.

The weird thing is that a collector can actually *improve* locality by
moving objects "close" to the things they refer to. In perl's case, the
collector could move the underlying value representation close to the PMC
that refers to it. (But we may want to pin a PMC so that foreign code
can keep references to it. Argh.)

> (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)

If you mean small as in "tight loop" then I agree. If you mean small as
in a "quick one liner" then I'm not sure. The quick one liners run quickly
and speeding memory management up/down by 100% might not even be noticeable.

> 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.

The electrons are re-used whether you allocate a new object or not... ;)

> 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.

Mark-sweep doesn't have a cheap allocator or good locality. At this point
in history, I think if we don't go with a more advanced system we're not

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