GC performance - was Re: [gclist] GC topics

[David Chase]

> Before I get another dozen of messages telling me how wrong I can 
> be:

> - I was referring to implementing a GC within a compiler. I am not
>   talking about uncooperative environments, for which I do not
>   think that any other solution than conservative GC can be implemented.

I think there are some major differences in our assumptions.  If 
you are working with a closed system, then it is true that it is 
not hard to implement precise GC.  How often do you get to do this?  
Your point is perhaps purely academic.

> - While it can be a pragmatic issue, I don't believe that the ability
>   to plug a GC in an existing system tells much about how easy it
>   can be to implement one. 

As it happens, it is also easy to write a conservative GC.

> - Quite amazingly, no one seems to mention the possible advantages of 
>   precise GC.

If there's no hope of using precise GC (because of uncooperative 
compilers and/or libraries) then its advantages, possible or actual, 
are not useful.  Furthermore, it appears that most of the advantages 
are less dramatic than theory would predict.  At least, that's what 
I get from reading papers by Wilson and by Boehm.  There's also system 
costs -- if I use a conservative GC, I can, in practice, make use 
of an already-written compiler that performs a number of optimizations. 
If I use precise GC, that's probably not an option.  The GC may be 
faster, but if the rest of the code is slower (because it is underoptimized) 
what's the point?  

speaking for myself,

David Chase