GC performance - was Re: [gclist] GC topics

[Darius Blasband]

> 
> > In any case, I think we agree on the fact that precise GC is far easier,
> > and globally more reliable and faster than conservative GC's...
> 
> This is completely wrong.  Precise garbage collection, especially 
> in the presence of an uncooperative compiler, is quite hard indeed.  
> The Boehm-Weiser collector is as close to plug-and-play as you can 
> hope to find, and I've ported it (easily) in the past, and I've written 
> a conservative garbage collector from scratch in relatively little 
> time.  Even when I think about making a compiler more cooperative, 
> my paper designs still involve use of a conservative, or somewhat 
> conservative, collector.
> 
> speaking for myself,
> 
> 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.
- 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. 
- Quite amazingly, no one seems to mention the possible advantages of 
  precise GC. It is more portable (or at least, this is what my experience
  seems to tell, even on esoteric architectures such as an IBM mainframe), 
  and I guess (no data available...) that the actual GC process can be much 
  efficient, since it knows where usable data is, it does not have to guess. 
  Then, in mission-critical environments (not referring to real-time), my
  (admittedly, personal) opinion is that the risk of erratic behaviour
  of conservative GC might be a little bit too much to endure, even if
  this risk happens to be pretty small in practice.
  
I don't know. Is there anything basically stupid in what I wrote ?

Regards...

Darius