From: Rob Pike Date: Tue, 17 Jul 2018 09:57:24 +0000 (+1000) Subject: doc: improve the garbage collection discussion X-Git-Tag: go1.11beta2~67 X-Git-Url: http://www.git.cypherpunks.su/?a=commitdiff_plain;h=3a28a711db15efd97c7675fccf0d2d0f2245a99b;p=gostls13.git doc: improve the garbage collection discussion Bring it up to date with recent terminology, mention new approaches such as in Rust, and link to the new blog post. Change-Id: I1d0b121e6f8347c3cf2c8ca0d8adc8285ce59ef1 Reviewed-on: https://go-review.googlesource.com/124475 Reviewed-by: Brad Fitzpatrick Reviewed-by: Ian Lance Taylor --- diff --git a/doc/go_faq.html b/doc/go_faq.html index bb8720ed11..1330309d34 100644 --- a/doc/go_faq.html +++ b/doc/go_faq.html @@ -267,7 +267,7 @@ Do Go programs link with C/C++ programs? It is possible to use C and Go together in the same address space, but it is not a natural fit and can require special interface software. Also, linking C with Go code gives up the memory -safety and stack management guarantees that Go provides. +safety and stack management properties that Go provides. Sometimes it's absolutely necessary to use C libraries to solve a problem, but doing so always introduces an element of risk not present with pure Go code, so do so with care. @@ -2391,20 +2391,25 @@ Go can use the standard syntax one line at a time without special rules. Why do garbage collection? Won't it be too expensive?

One of the biggest sources of bookkeeping in systems programs is -memory management. -In languages in which it is done manually, +managing the lifetimes of allocated objects. +In languages such as C in which it is done manually, it can consume a significant amount of programmer time and is often the cause of pernicious bugs. -We felt it was critical to eliminate that -programmer overhead, and advances in garbage collection +Even in languages like C++ or Rust that provide mechanisms +to assist, those mechanisms can have a significant effect on the +design of the software, often adding programming overhead +of its own. +We felt it was critical to eliminate such +programmer overheads, and advances in garbage collection technology in the last few years gave us confidence that it -could be implemented with low enough overhead and no significant -latency. +could be implemented cheaply enough, and with low enough +latency, that it could be a viable approach for networked +systems.

-Another issue is that a large part of the difficulty of concurrent -and multi-threaded programming is memory management; +A related issue is that a large part of the difficulty of concurrent +and multi-threaded programming is the object lifetime problem: as objects get passed among threads it becomes cumbersome to guarantee they become freed safely. Automatic garbage collection makes concurrent code far easier to write. @@ -2418,9 +2423,19 @@ Finally, concurrency aside, garbage collection makes interfaces simpler because they don't need to specify how memory is managed across them.

+

+This is not to say that the recent work in languages +like Rust that bring new ideas to the problem of to managing +resources is misguided; we encourage this work and are excited to see +how it evolves. +But Go takes a more traditional approach by addressing +object lifetimes through +garbage collection, and garbage collection only. +

+

The current implementation is a mark-and-sweep collector. -If the machine is a multiprocessor, it runs on a separate CPU +If the machine is a multiprocessor, the collector runs on a separate CPU core in parallel with the main program. Major work on the collector in recent years has reduced pause times often to the sub-millisecond range, even for large heaps, @@ -2428,6 +2443,10 @@ all but eliminating one of the major objections to garbage collection in networked servers. Work continues to refine the algorithm, reduce overhead and latency further, and to explore new approaches. +The 2018 +ISMM keynote +by Rick Hudson of the Go team +describes the progress so far and suggests some future approaches.