[gclist] Precise GC's performance

[Charles Fiterman]

> 
> Hello everyone !
> 
> Following the (harsh) debate between precise and conservative GC's, I have
> been measuring the real cost of precise GC as supported by YAFL. So, let's
> try to be precise (:-) about what we measure: I have not been able to measure
> the difference between the actual GC processes itself yet (Soon, I hope).
> I did produce a version of the compiler which does not generate any
> GC-related code, and I ran a set of benchmark programs with enough memory
> so that GC is never called. Then, I ran the same set programs compiled
> with the normal GC-aware code generation, and it appears that keeping track 
> of the objects which are accessible at any given time (precise GC, thus)
> costs 17% of the total execution time. Given a few simple optimizations, 
> I think I can shrink this figure below the 15%, but I am not even sure
> it is worth the trouble... 

The question is what kind of collector you have for precise collection.
If you have a generational collector then the malloc becomes faster than
an ordinary malloc. Substuting the null collector is not a fair test.
YAFL must somehow figure out how to free storage. That has a cost. Manual
adhoc methods of collection are often far more expensive than highly
the tuned ones you find in garbage collectors.

Our users often tell us that they linked in our collector and things ran
faster. 

Also collectors can move collection into idle time. Manual methods of
deallocation rarely can do that.