qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-11 22:10:22 -07:00
Code Releases Activity

doc: add FAQ about large binaries and stack vs heap allocation

Browse Source 
doc: add internationalization to roadmap

R=rsc, r, r2
CC=golang-dev
https://golang.org/cl/4251047
This commit is contained in:
Andrew Gerrand 2011-03-01 21:35:46 +11:00
parent 41a23ca08b
commit 4b0ecd3f49
2 changed files with 39 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/devel/roadmap.html
View File

@ -47,6 +47,8 @@ App Engine support.
Improved CGO including some mechanism for calling back from C to Go.
<li>
Improved implementation documentation.
<li>
Comprehensive support for internationalization.
</ul>
<h4 id="Gc_roadmap">

37
doc/go_faq.html
View File

@ -677,6 +677,28 @@ floating-point numbers.
The default size of a floating-point constant is <code>float64</code>.
</p>
<h3 id="stack_or_heap">
How do I know whether a variable is allocated on the heap or the stack?</h3>
<p>
From a correctness standpoint, you don't need to know.
Each variable in Go exists as long as there are references to it.
The storage location chosen by the implementation is irrelevant to the
semantics of the language.
<p>
The storage location does have an effect on writing efficient programs.
When possible, the Go compilers will allocate variables that are
local to a function in that function's stack frame. However, if the
compiler cannot prove that the variable is not referenced after the
function returns, then the compiler must allocate the variable on the
garbage-collected heap to avoid dangling pointer errors.
<p>
In the current compilers, the analysis is crude: if a variable has its address
taken, that variable is allocated on the heap. We are working to improve this
analysis so that more data is kept on the stack.
<h2 id="Concurrency">Concurrency</h2>
<h3 id="What_operations_are_atomic_What_about_mutexes">
@ -934,6 +956,21 @@ segmented stacks for goroutines.
Work is underway to provide the same stack management in
<code>gccgo</code>.
<h3 id="Why_is_my_trivial_program_such_a_large_binary">
Why is my trivial program such a large binary?</h3>
<p>
The gc tool chain (<code>5l</code>, <code>6l</code>, and <code>8l</code>) only
generate statically linked binaries. All Go binaries therefore include the Go
run-time, along with the run-time type information necessary to support dynamic
type checks, reflection, and even panic-time stack traces.
<p>
A trivial C "hello, world" program compiled and linked statically using gcc
on Linux is around 750 kB. An equivalent Go program is around 1.8 MB, but
that includes a more powerful runtime. We believe that with some effort
the size of Go binaries can be reduced.
<h2 id="Performance">Performance</h2>
<h3 id="Why_does_Go_perform_badly_on_benchmark_x">