This change allows the garbage collector to examine stack
slots that are determined as live and containing a pointer
value by the garbage collector. This results in a mean
reduction of 65% in the number of stack slots scanned during
an invocation of "GOGC=1 all.bash".
Unfortunately, this does not yet allow garbage collection to
be precise for the stack slots computed as live. Pointers
confound the determination of what definitions reach a given
instruction. In general, this problem is not solvable without
runtime cost but some advanced cooperation from the compiler
might mitigate common cases.
R=golang-dev, rsc, cshapiro
CC=golang-dev
https://golang.org/cl/14430048
Pass as a slice of strings instead. For 2-5 strings, implement
dedicated routines so no slices are needed.
static call counts in the go binary:
2 strings: 342 occurrences
3 strings: 98
4 strings: 30
5 strings: 13
6+ strings: 14
Why? C varags, bad for stack scanning and copying.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/36380043
Now that the map implementation is reading the keys and values from
arbitrary memory (instead of from stack slots), it needs to tell the
race detector when it does so.
Fixes#6875.
R=golang-dev, dave
CC=golang-dev
https://golang.org/cl/36360043
and methodValueCall directly. Instead, we inline their behavior
inside of reflect.call.
This change is required because otherwise we have a situation where
reflect.callXX calls makeFuncStub, neither of which knows the
layout of the args passed between them. That's bad for
precise gc & stack copying.
Fixes#6619.
R=golang-dev, dvyukov, rsc, iant, khr
CC=golang-dev
https://golang.org/cl/26970044
This change is part of the plan to get rid of all vararg C calls
which are a pain for getting exact stack scanning.
We allocate a chunk of zero memory to return a pointer to when a
map access doesn't find the key. This is simpler than returning nil
and fixing things up in the caller. Linker magic allocates a single
zero memory area that is shared by all (non-reflect-generated) map
types.
Passing things by reference gets rid of some copies, so it speeds
up code with big keys/values.
benchmark old ns/op new ns/op delta
BenchmarkBigKeyMap 34 31 -8.48%
BenchmarkBigValMap 37 30 -18.62%
BenchmarkSmallKeyMap 26 23 -11.28%
R=golang-dev, dvyukov, khr, rsc
CC=golang-dev
https://golang.org/cl/14794043
They were out of date and should refer to the source installation instructions.
Fixes#6783.
R=golang-dev, rsc, adg, dave
CC=golang-dev
https://golang.org/cl/28500043
Clarify that GOROOT should only be set when using a custom install path.
Remove NetBSD from binary install page (we don't provide binaries).
Remove "What's next" links from installation instructions.
Emphasize "How to Write Go Code" page.
Fixes#6613.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/28700043
This step makes it possible to upload the -osx10.x binaries
separately to their construction (after signing, for example).
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/28160043
- Use #' for function symbols
- Remove unused variables
- Use declare-function to shut up byte compiler
This is identical to CL 19010044 with one exception: Making sure
it doesn't break on Emacs 22.1
R=adonovan, bradfitz, shendaras
CC=golang-dev
https://golang.org/cl/20100043
Clang does not record the "size" field for pointer types,
so we must insert the size ourselves. We were already
doing this, but only for the case of pointer types.
For an array of pointer types, the setting of the size for
the nested pointer type was happening after the computation
of the size of the array type, meaning that the array type
was always computed as 0 bytes. Delay the size computation.
This bug happens on all Clang systems, not just FreeBSD.
Our test checked that cgo wrote something, not that it was correct.
FreeBSD's default clang rejects array[0] as a C struct field,
so it noticed the incorrect sizes. But the sizes were incorrect
everywhere.
Update testcdefs to check the output has the right semantics.
Fixes#6292.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/22840043
I know it's linked in the previous sentence, but this new link is where I want it to be while reading this sentence.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/21770043
