gccgo has problems using reflect.Call with functions that take and
return structs with no members. Prior to fixing that problem there, I
thought it sensible to add some tests of this situation.
Update #6761
First contribution to Go, apologies in advance if I'm doing it wrong.
R=golang-dev, dave, minux.ma, iant, khr, bradfitz
CC=golang-dev
https://golang.org/cl/26570046
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
Failure occurred when using reflect.Call to pass a func value
following a non-pointer value.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/14186043
pointer. An example that triggers the bad behavior on a 64bit
machine http://play.golang.org/p/GrNFakAYLN
rv1 := reflect.ValueOf(complex128(0))
rt := rv1.Type()
rv2 := rv1.Convert(rt)
rv3 := reflect.New(rt).Elem()
rv3.Set(rv2)
Running the code fails with the following:
panic: reflect: internal error: storeIword of 16-byte value
I've tested on a 64bit machine and verified this fixes the panic. I
haven't tested on a 32bit machine so I haven't verified the other
cases, but they follow logically.
R=golang-dev, r, iant
CC=golang-dev
https://golang.org/cl/12805045
Update #5000
Should reduce the flakiness a little. Malloc counting is important
to general testing but not to the build dashboard, which uses -short.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/12866047
See issue 4949 for a full explanation.
Allocs go from 1 to zero in the non-addressable case.
Fixes#4949.
BenchmarkInterfaceBig 90 14 -84.01%
BenchmarkInterfaceSmall 14 14 +0.00%
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12646043
you do reflect.call with too big an argument list.
Not worth the hassle.
Fixes#6023Fixes#6033
R=golang-dev, bradfitz, dave
CC=golang-dev
https://golang.org/cl/12485043
This CL also replaces similar loops in other stdlib
package tests with calls to AllocsPerRun.
Fixes#4461.
R=minux.ma, rsc
CC=golang-dev
https://golang.org/cl/7002055
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 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
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
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
Got rid of all the magic mystery globals. Now
for %N, %T, and %S, the flags +,- and # set a sticky
debug, sym and export mode, only visible in the new fmt.c.
Default is error mode. Handle h and l flags consistently with
the least side effects, so we can now change
things without worrying about unrelated things
breaking.
fixes#2361
R=rsc
CC=golang-dev
https://golang.org/cl/5316043
Had been allowing it for use by fmt, but it is too hard to lock down.
Fix other packages not to depend on it.
R=r, r
CC=golang-dev
https://golang.org/cl/5266054
This allows code that wants to handle
[]byte separately to get at the actual slice
instead of just at individual bytes.
It seems to come up often enough.
R=r
CC=golang-dev
https://golang.org/cl/4942051