The spec mostly uses the term embedded.
It's too late to change the field name but at least fix the docs.
Fixes#4514.
R=golang-dev, dave
CC=golang-dev
https://golang.org/cl/7235080
The new garbage collector (CL 6114046) may find the fake *[]byte value
and interpret its contents as bytes rather than as potential pointers.
This may lead the garbage collector to free memory blocks that
shouldn't be freed.
R=dvyukov, rsc, dave, minux.ma, remyoudompheng, iant
CC=golang-dev
https://golang.org/cl/7000059
The existing algorithm did not properly propagate the type
count from one level to the next, and as a consequence it
missed collisions.
Properly propagate multiplicity (count) information to the
next level.
benchmark old ns/op new ns/op delta
BenchmarkFieldByName1 182 180 -1.10%
BenchmarkFieldByName2 6273 6183 -1.43%
BenchmarkFieldByName3 49267 46784 -5.04%
Fixes#4355.
R=rsc
CC=golang-dev
https://golang.org/cl/6821094
In order to add these, we need to be able to find references
to such types that already exist in the binary. To do that, introduce
a new linker section holding a list of the types corresponding to
arrays, chans, maps, and slices.
To offset the storage cost of this list, and to simplify the code,
remove the interface{} header from the representation of a
runtime type. It was used in early versions of the code but was
made obsolete by the kind field: a switch on kind is more efficient
than a type switch.
In the godoc binary, removing the interface{} header cuts two
words from each of about 10,000 types. Adding back the list of pointers
to array, chan, map, and slice types reintroduces one word for
each of about 500 types. On a 64-bit machine, then, this CL *removes*
a net 156 kB of read-only data from the binary.
This CL does not include the needed support for precise garbage
collection. I have created issue 4375 to track that.
This CL also does not set the 'algorithm' - specifically the equality
and copy functions - for a new array correctly, so I have unexported
ArrayOf for now. That is also part of issue 4375.
Fixes#2339.
R=r, remyoudompheng, mirtchovski, iant
CC=golang-dev
https://golang.org/cl/6572043
The old code worked with gc, I assume because the linker
unified identical strings, but it failed with gccgo.
R=rsc
CC=gobot, golang-dev
https://golang.org/cl/6826063
The previous version was created by an idiot. This time, Rog Peppe
wrote the text. Thanks, Rog.
(== doesn't work on slices in general, so it makes no sense to
talk about in the context of DeepEqual.)
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/6566054
This CL makes the runtime understand that the type of
the len or cap of a map, slice, or string is 'int', not 'int32',
and it is also careful to distinguish between function arguments
and results of type 'int' vs type 'int32'.
In the runtime, the new typedefs 'intgo' and 'uintgo' refer
to Go int and uint. The C types int and uint continue to be
unavailable (cause intentional compile errors).
This CL does not change the meaning of int, but it should make
the eventual change of the meaning of int on amd64 a bit
smoother.
Update #2188.
R=iant, r, dave, remyoudompheng
CC=golang-dev
https://golang.org/cl/6551067
The old code was a depth first graph traversal that could, under the
right conditions, end up re-exploring the same subgraphs multiple
times, once for each way to arrive at that subgraph at a given depth.
The new code uses a breadth first search to make sure that it only
visits each reachable embedded struct once.
Also add fast path for the trivial case.
benchmark old ns/op new ns/op delta
BenchmarkFieldByName1 1321 187 -85.84%
BenchmarkFieldByName2 6118 5186 -15.23%
BenchmarkFieldByName3 8218553 42112 -99.49%
R=gri, r
CC=golang-dev
https://golang.org/cl/6458090
Occasionally I see:
--- FAIL: TestAllocations-15 (0.00 seconds)
all_test.go:1575: 6 mallocs after 100 iterations
Tested:
$ go test -cpu=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20 reflect
R=golang-dev, dsymonds, r
CC=golang-dev
https://golang.org/cl/6354063
unsafe: delete Typeof, Reflect, Unreflect, New, NewArray
Part of issue 2955 and issue 2968.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5650069
Unexports runtime.MemStats and rename MemStatsType to MemStats.
The new accessor requires passing a pointer to a user-allocated
MemStats structure.
Fixes#2572.
R=bradfitz, rsc, bradfitz, gustavo
CC=golang-dev, remy
https://golang.org/cl/5616072
Consequently, remove many package Makefiles,
and shorten the few that remain.
gomake becomes 'go tool make'.
Turn off test phases of run.bash that do not work,
flagged with $BROKEN. Future CLs will restore these,
but this seemed like a big enough CL already.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5601057
All but 3 cases (in gcimporter.go and hixie.go)
are automatic conversions using gofix.
No attempt is made to use the new Append functions
even though there are definitely opportunities.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5447069
Equality on structs will require arbitrary code for type equality,
so change algorithm in type data from uint8 to table pointer.
In the process, trim top-level map structure from
104/80 bytes (64-bit/32-bit) to 24/12.
Equality on structs will require being able to call code generated
by the Go compiler, and C code has no way to access Go return
values, so change the hash and equal algorithm functions to take
a pointer to a result instead of returning the result.
R=ken
CC=golang-dev
https://golang.org/cl/5453043
Making Value opaque means we can drop the interface kludges
in favor of a significantly simpler and faster representation.
v.Kind() will be a prime candidate for inlining too.
On a Thinkpad X201s using -benchtime 10:
benchmark old ns/op new ns/op delta
json.BenchmarkCodeEncoder 284391780 157415960 -44.65%
json.BenchmarkCodeMarshal 286979140 158992020 -44.60%
json.BenchmarkCodeDecoder 717175800 388288220 -45.86%
json.BenchmarkCodeUnmarshal 734470500 404548520 -44.92%
json.BenchmarkCodeUnmarshalReuse 707172280 385258720 -45.52%
json.BenchmarkSkipValue 24630036 18557062 -24.66%
benchmark old MB/s new MB/s speedup
json.BenchmarkCodeEncoder 6.82 12.33 1.81x
json.BenchmarkCodeMarshal 6.76 12.20 1.80x
json.BenchmarkCodeDecoder 2.71 5.00 1.85x
json.BenchmarkCodeUnmarshal 2.64 4.80 1.82x
json.BenchmarkCodeUnmarshalReuse 2.74 5.04 1.84x
json.BenchmarkSkipValue 77.92 103.42 1.33x
I cannot explain why BenchmarkSkipValue gets faster.
Maybe it is one of those code alignment things.
R=iant, r, gri, r
CC=golang-dev
https://golang.org/cl/5373101