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 14:11
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
Message ID:
At 04:53 PM 2/9/2001 -0500, Ken Fox wrote:
>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.

Yeah, but while O(x*n) and O(y*n) are equivalent (assuming x an y are 
constants) theoretically, it can make a biggish difference in real life if 
x and y are, say, 1 and 4. Some objects do have non-trivial setup costs. 
(Such as those that open persistent, reusable connections to remote systems...)

Granted in this case we're talking about pure memory allocation issues, as 
that's all that GCs cover, so you probably won't see more than a few 
hundred cycles difference for that.

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

I'm not sure what scheme we'll be using, but some sort of generational 
semi-space scheme seems likely, if for no other reason than to reduce the 
pauses we'll get when GC fires off.

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

PMC structures will be allocated in a different area than the data they 
contain, and they'll also be of fixed location. Not great, but short of 
imposing a double-deref penalty (with the corresponding chance of 
programmer error) there's nothing for it. Extension code definitely is a 
pain in this case.

We can still try and make things more local so that, for example, all the 
string data for the scalars in a string array get compacted together.

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

I was thinking of things that may process a lot of data but in small 
pieces, like the command-line greps and suchlike things. They can take a 
while on 100M files, but that shouldn't be because they've eaten 200M of 
RAM in the process...

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

Yeah, I was sloppy in my terminology. Some of the generational garbage 
collectors look rather nice, and whatever we choose, the original mark and 
sweep won't be it, for pause times if nothing else. (If it weren't for the 
pauses, pretty much anything is better than refcounts...)


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