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