OSNews thread here degenerates into GC vs not

[Mike Parker]

Mike Capp wrote:
> Sean Kelly wrote:
> 
>> That sounds like bad program design rather than
>> bad GC design.  Were the app written using
>> conventional allocation it would either be visibly
>> slow or leak like a sieve.
> 
> Probably. And I suspect the codebase we use it on is larger than usual. But then,
> you could offer the same retort to any reported "for real" GC problem.
> 

One thing I've learned during my years with Java is that most "GC 
problems" are really programmer problems. Such issues can be avoided by 
"coding to the GC." Unfortunately, this is something that too many 
developers just don't get. Still there are problems that can't be worked 
around in obvious ways in code. To eliminate those, Sun goes the extra 
mile via Java's tools to analyze GC behavior and the command line 
parameters to fine-tune it, even allowing you to select between several 
different implementations. That will take care of all but the rare 
border case.

I've not worked with C# more than in passing, so I don't know what sort 
of tools or options are available to tune the GC. It would be great to 
have such capabilities in D. I haven't used D extensively enough to know 
what "coding to the GC" means for the current implementations, but 
developers who do understand it should be able to avoid the lion's share 
of issues.