My wish for 2015...

[Delirious via Digitalmars-d]

On Saturday, 20 December 2014 at 22:11:35 UTC, Xinok wrote:
> (2) Furthermore, we need to improve the performance of the 
> garbage collector.

"Performance" is a complex issue in the case of GCs. There is not 
"highest performance GC", only GCs optimally tuned for certain 
scenarios. While a simple, imprecise, mark-and-sweep collector 
like the one used by D right now is not that complicated, modern, 
industrial GCs are very complex.

There are many decisions to be made and there is no single 
"right" answer.

At this point I would like to quote a post about the evolution of 
the Go garbage collector because Go originally had a primitive GC 
too but is now far head of D's by any standard:



Plans for Go 1.4+ garbage collector:

     hybrid stop-the-world/concurrent collector
     stop-the-world part limited by a 10ms deadline
     CPU cores dedicated to running the concurrent collector
     tri-color mark-and-sweep algorithm
     non-generational
     non-compacting
     fully precise
     incurs a small cost if the program is moving pointers around
     lower latency, but most likely also lower throughput, than Go 
1.3 GC

Go 1.3 garbage collector updates on top of Go 1.1:

     concurrent sweep (results in smaller pause times)
     fully precise

Go 1.1 garbage collector:

     mark-and-sweep (parallel implementation)
     non-generational
     non-compacting
     mostly precise (except stack frames)
     stop-the-world
     bitmap-based representation
     zero-cost when the program is not allocating memory (that is: 
shuffling pointers around is as fast as in C, although in 
practice this runs somewhat slower than C because the Go compiler 
is not as advanced as C compilers such as GCC)
     supports finalizers on objects
     there is no support for weak references

Go 1.0 garbage collector:

     same as Go 1.1, but instead of being mostly precise the 
garbage collector is conservative. The conservative GC is able to 
ignore objects such as []byte.

Replacing the GC with a different one is controversial, for 
example:

     except for very large heaps, it is unclear whether a 
generational GC would be faster overall
     package "unsafe" makes it hard to implement fully precise GC 
and compacting GC