Google announced the release of Go 1.5 today. This new version of the programming language and its associated tooling includes many performance improvements, as well as fundamental changes to the runtime and compiler.
Previously, the Go compiler and runtime included C code, but all traces of C have been expunged. The Go runtime and compiler are now written entirely in Go and assembly as of this release.
(Related: A word about Go 1.4)
There were numerous changes in this release, including one that may break existing code that is not expecting to run on multiple cores. Instead of defaulting to one core, the Go 1.5 runtime now defaults to running on however many cores are available.
Garbage collection saw major improvements in this release, something that should please performance-hungry developers. According to the Go 1.5 road map, written by Richard L. Hudson last year, “The goal of the Go 1.5 Garbage Collector (GC) is to reduce GC latency, making Go acceptable for implementing a broad spectrum of systems requiring low response times. Quantitatively, this means that for adequately provisioned machines limiting GC latency to less than 10ms, with mutator (Go application code) availability of more than 40ms out of every 50ms.
“Hardware provisioning should allow for in-memory heap sizes twice as large as reachable memory and 25% of CPU cycles, typically one out of four hardware threads, available for GC tasks. These goals align with a future with ever-increasing numbers of hardware threads and an ever-increasing amount of memory, all within an ever-decreasing power and expense budget.”
Those changes have now come to fruition, with the implementation of concurrent garbage collection in Go 1.5. This is not the end of the improvements planned for Go’s garbage collection, however. Version 1.6 should expand the throughput capacity for the platform, and for the garbage collector.
From the road map, Hudson wrote that “1.6 will most likely be used to improve throughput by adding bump pointer allocation as well as a generational copy collector for nursery (new) spaces. The mature (old) space will be managed using our concurrent GC. The nurseries will be sized so that they can be collected in 10ms. This pause will be within the range of the 1.5 collector, which will ensure a continuity of runtime environments for Go application as we move forward. The decision to prioritize concurrency in 1.5 over throughput in 1.6 was a conscious choice intended to accelerate support for new users.”
