Warp wrote:
>   So GC is basically a selfish and greedy memory allocation engine which
> cares only about itself, not anything else in the same system which might
> have some use for that wasted memory.

You could say it's a time-space trade-off.  You know, I almost never 
have a situation where I have two programs running and I'm paging 
because of it. :-)

>   Doesn't this also mean that the GC runs a lot more often than would be
> strictly necessary? 

Assuming you mean "allocating everything on the heap" when you say 
"this"....

> Isn't that kind of counter-productive? 

Only if your language has a stack and isn't functional and is 
single-threaded, I suppose. If your language definition is that the 
stack frames are stored on the heap (for, say, closure purposes), or you 
need to allocate a separate stack of some size for each thread anyway, 
or you tend to overwrite the same memory address with lots of different 
things at different times (unlike, say, LISP, where you tend to build 
new structures reusing parts of old ones instead of overwriting what you 
already have), then allocating lots of short-lived stuff on the heap 
makes sense.

Of course, systems like Smalltalk *do* really and truly have a stack 
(now), exactly for performance reasons. It just doesn't look that way, 
because it'll copy stack frames into the heap if you try to access them 
as "objects".  (Then again, Smalltalk didn't have conditional 
statements, either, in the semantics of the language. Just messages sent 
to booleans along with a couple blocks of text, and a method dispatch 
that evaluated the first block in the True class and the second block in 
the False class, which I thought was pretty cool. :-)

 > Not only is memory wasted (and thus away from other processes),

Remember that the original GC stuff was done on systems (Lisp, 
Smalltalk, etc) where the interpreter *was* the OS, so "taking away from 
other processes" doesn't always make sense.

But yes, some memory is "wasted" for some meaning of the word "wasted". 
Not unlike stack space is "wasted" if you're not about to overflow the 
stack.

It's also "wasted" if you are willing to spend more time on expert 
programmers who never make a mistake and hence never corrupt memory, 
rather than spending more money to buy some RAM. And indeed, when RAM is 
expensive (like in embedded devices), one tends not to see too many 
GC'ed systems.

And with some OS help, you can actually get pretty decent performance 
during collections. The ability to mark pages "manually" to say which 
are more likely to be needed soon, the ability to trap writes to 
particular pages so you can mark them as "the GC will need to examine 
this on the next sweep", the ability to pre-fetch paged-out pages while 
you're processing this one (i.e., read-ahead for page faults), etc.

> but part of the speed
> benefits in doing so are lost by having to run GC sweeps more often.

Running GCs too often is indeed a performance-limiting problem. That's 
one of the reasons that people writing collectors spend so much time 
trying to make them fast, and why there are so many different types of 
collectors (compared to, say, only a couple different kinds of stacks).

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message