== Quote from Leandro Lucarella (l...@llucax.com.ar)'s article > dsimcha, el 15 de julio a las 19:23 me escribiste: > > == Quote from Bane (branimir.milosavlje...@gmail.com)'s article > > > Anyway, I'm here bitching myself :) Just want to say that idea to have > > > more than > > one GC type to chose when compiling would be very interesting thing, if > > single > > implementation can't be good for all cases. > > > > If I had to chose one topic with most bitchin' on this newsgroup I have > > impression it would be the one about GC. They usually goes from 'GC managed > > programs are slow, D ain't good enough', to 'language X has better GC than > > D', to > > ' GC that D has is bad at Z'. > > > > > > > > Why not make D summer of code - write your own GC optimized for special > > > > case > > of XYZ, send it, bundle all up in D with compiler switch '--useGC=XYZ'. > > That is > > only way to really compare what is best for special case. > > > > > > > > If/when we have enough manpower to write/maintain multiple GC's, here are > > some GC > > designs that can be either optimizations or pessimizations depending on use > > case: > > > > 1. Precise heap scanning (i.e. in the absence of copying/heap compaction). > > If > > you allocate mostly small objects, you're probably very seldom bitten by > > false > > pointers and the O(1) overhead per block needed to store type info may be > > significant. If you allocate mostly large objects, you've probably been > > eaten > > alive by false pointers and the O(1) per block overhead is negligible to > > you. > > > > 2. Concurrent collection. If you use threads for concurreny/latency > > reasons, > > this can be a boon. If you use threads for parallelism/throughput reasons, > > or > > write single-threaded code, this is a complete waste. > Not completely, if you have a multi-core, suddenly your program becomes > multi-threaded and uses more than 1 core. In that case, a concurrent GC > could improve the overall performance of the application.
In theory. I thought that in practice concurrent GC's (I'm not talking about the case of thread-local heaps) are always slower throughput-wise than stop-the-world.
