[gclist] GC topics

[Darius Blasband]

> 
> Your number is interesting, but not as interesting as it could be.  The problem 
> is in what you're comparing.  The system with no GC code also has no code to 
> explicitly free memory, no code to compact memory (even to coallesce adjacent 
> free blocks), perhaps even no code to search for an appropriate block.  (Without 
> knowing what your GC does, we can't guess at that.  The allocator that goes 
> along with a compacting or copying collector, for example, simply does a compare 
> and an increment - it can assume that all free memory is in one contiguous 
> block.)
> 
> If the "comparison" system did actual allocation and deallocation, it would cost 
> more.  How much more depends on many details.  Most comparisons of systems with 
> garbage collection to systems without it, but with decent allocators, show 
> around a 10% cost (folk result).  That's a fairer comparison, but even so it's 
> inherently suspect:  Code written assuming a garbage collector is organized 
> differently from code that has to do explicit allocation and deallocation.  
> Code that assumes GC is probably much more likely to allocate dynamic memory, 
> since it's so easy:  LISP programmers don't go out of their way to avoid CONS 
> unless they absolutely have to!  This may lead to code that does more allocation 
> than is strictly necessary, making GC systems look slower.  On the other hand, 
> code written without a GC, especially well-structured, modular code that has to 
> be able to run safely in complex environments - i.e., just the sort of code we'd 
> like to encourage! - may end up making private copies of data so as to avoid 
> coupling through various "must delete when finished" constraints.  This can make 
> *non*-GC code look slower.  How these two effects (and others) interact in any 
> given program is impossible to predict, but either could easily swamp any 
> "inherent" difference - whatever that means - between the GC and non-GC choices.
> 
> 							-- Jerry
> 
These were not the issues we were considering: since we use a *precise* 
garbage collector, which keeps track of accessible data in runtime rather
than relying on some pattern matching algorithm on the stack to check
what might actually be pointer to accessible data, what we wanted to measure
was how much time this "keeping track" took. So, 20% of the total execution
time is required (someone might even say "wasted") just to keep track
of all accessible references, even if no new allocation is performed. 

I see these 20% as the cost for precise GC when compared to conservative
GC, and, given the other advantages of precise GC (determinism, portability,
and performance *during* the GC process), I thought it was worth it.

The issue here is not only to compare this with non-GC systems, but also
with conservative GC systems, specially when considering that most of
the performance issue regarding GC relies implicitely on conservative
ones. We have never had a complaint about a system being hung because GC
was going on - it simply happens too fast - but we have no idea so far
whether we are just being lucky, or is our precise scheme so much more
efficient than the conservative scheme *during* GC. Anyone has some figure ?

Darius