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

Reply via email to