It appears to have been unused since https://go.dev/cl/298670
in April 2021, as that change removed its only use.
It is always in the git history if it is needed again.
Change-Id: Ie55d059c102dfaa75bd253e09d48a4b30f45e941
Reviewed-on: https://go-review.googlesource.com/c/go/+/483136
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Fixes the misuse of "a" vs "an", according to English grammatical
expectations and using https://www.a-or-an.com/
Change-Id: I53ac724070e3ff3d33c304483fe72c023c7cda47
Reviewed-on: https://go-review.googlesource.com/c/go/+/480536
Run-TryBot: shuang cui <imcusg@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
These are replaced by unsafe.String etc, which were added in Go 1.20.
Per https://go.dev/wiki/Deprecated, we must wait until Go 1.21
to mark them deprecated.
Fixes#56906.
Change-Id: I4198c3f3456e9e2031f6c7232842e187e6448892
Reviewed-on: https://go-review.googlesource.com/c/go/+/452762
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Russ Cox <rsc@golang.org>
While at it, also use concrete type for non-interface type test.
Change-Id: Ie468c30ee31ba99ef8f9a810d3be851fd37b9b43
Reviewed-on: https://go-review.googlesource.com/c/go/+/478356
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Previously TryBot-tested with bucket bits = 4.
Also tested locally with bucket bits = 5.
This makes it much easier to change the size of map
buckets, and hopefully provides pointers to all the
code that in some way depends on details of map layout.
Change-Id: I9f6669d1eadd02f182d0bc3f959dc5f385fa1683
Reviewed-on: https://go-review.googlesource.com/c/go/+/462115
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Change-Id: I75aef6bf957939fae8b680214f5923dc2713a5cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/452935
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
There has been no proposal discussion about adding these notices.
Also, even if we did decide to add them, then since their replacements
are only appearing in Go 1.20, go.dev/wiki/Deprecation says that we
should wait until Go 1.22 to add the deprecation notice.
Filed #56906 for the proposal discussion.
Fixes#56905.
Change-Id: If86cce65aa00b4b62b2b18e82503431dcbdbcfed
Reviewed-on: https://go-review.googlesource.com/c/go/+/452761
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #46746
Change-Id: I75ddb9ce24cd3394186562dae156fef9fe2d55d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/447798
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I871a747b4b47bccc889f2fdc93a2bcebb041b719
Reviewed-on: https://go-review.googlesource.com/c/go/+/447895
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Assuming the two values are valid and non-comparable, Equal should panic.
x := reflect.ValueOf([]int{1, 2, 3})
x.Equal(x) // can not report false, should panic
Assuming one of them is non-comparable and the other is invalid, it should
always report false.
x := reflect.ValueOf([]int{1, 2, 3})
y := reflect.ValueOf(nil)
x.Equal(y) // should report false
For #46746.
Change-Id: Ifecd77ca0b3de3019fae2be39048f9277831676c
Reviewed-on: https://go-review.googlesource.com/c/go/+/440037
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The Grow method is like the proposed slices.Grow function
in that it ensures that the slice has enough capacity to append
n elements without allocating.
The implementation of Grow is a thin wrapper over runtime.growslice.
This also changes Append and AppendSlice to use growslice under the hood.
Fixes#48000
Change-Id: I992a58584a2ff1448c1c2bc0877fe76073609111
Reviewed-on: https://go-review.googlesource.com/c/go/+/389635
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This change adds the arenas package and a function to reflect for
allocating from an arena via reflection, but all the new API is placed
behind a GOEXPERIMENT.
For #51317.
Change-Id: I026d46294e26ab386d74625108c19a0024fbcedc
Reviewed-on: https://go-review.googlesource.com/c/go/+/423361
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Imagine that initFuncTypes is called with n=3, funcTypes will be
[nil, nil, nil, **reflect.rtype] afterward, then it's called with n=2.
The current implementation will copy funcTypes because funcTypes[2] is
nil. This is unnecessary. It should make a new slice and copy funcTypes
into it only when n >= len(funcTypes).
Updates #56011.
Change-Id: Ia093d2f550d6924a4c58bcd21325093e32b40baa
GitHub-Last-Rev: a599eae7c2
GitHub-Pull-Request: golang/go#56024
Reviewed-on: https://go-review.googlesource.com/c/go/+/438395
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
CL 425314 made creating funcTypes using StructOf, and using a mutex to
protect read+write to funcTypes. However, after initializing funcTypes,
it is accessed in FuncOf without holding lock, causing a race.
Fixing it by returning the n-th Type directly from initFuncTypes, so the
accessing funcTypes will always be guarded by a mutex.
Fixes#56011
Change-Id: I1b50d1ae342943f16f368b8606f2614076dc90fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/437997
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
For #46746
Change-Id: Ic7a31ddf7cd6bf6dd0db6b9eb3fee68fc180f72e
Reviewed-on: https://go-review.googlesource.com/c/go/+/435277
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
follow the TODO to use StructOf, this cl can save the used memory.
for example, old code alloc [128]*rtype for func with 65 arguments(in+out),
this cl change to alloc [65]*rtype to save memory.
Change-Id: I1494bb6b3524d0d46869c3f24a628fec88119d8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/425314
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
using Type.Comparable to simplify the Value.Comparable,
and return true directly when exit the for loop of kind == array and elements type is interface or array or struct.
Change-Id: Ib0b06a70642ba24c9215c69e7d619960fbeeed90
Reviewed-on: https://go-review.googlesource.com/c/go/+/426457
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: xie cui <523516579@qq.com>
Change-Id: If36e9fd7d6b1993ca2d0d382e7fa52212170c798
Reviewed-on: https://go-review.googlesource.com/c/go/+/425481
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
all_test.go is quite big, so let it contain tests only.
Change-Id: I5003db4a8b1e2384ea8470f5e89e1c26d61d10ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/429759
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Jenny Rakoczy <jenny@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
After we deprecated reflect.{SliceHeader, StringHeader}, it is recommended
to use unsafe.{Slice, String} to replace its work. However, the compiler
and linker cannot be migrated for the time being.
As a temporary strategy, using the "internal/unsafeheader" package like
other code is the most suitable choice at present.
For #53003.
Change-Id: I69d0ef72e2d95caabd0706bbb247a719d225c758
Reviewed-on: https://go-review.googlesource.com/c/go/+/429755
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: hopehook <hopehook@golangcn.org>
As discussed in CL 401434 there are substantial misuses of these in the
wild, and they are a potential source of unsafety even for code that
does not use them directly.
Since proposal #53003 has already been implemented, now is the right
time to deprecate reflect.{SliceHeader, StringHeader}.
For #53003.
Change-Id: I724cf46d4b22d2ed3cbf2b948e6aac5ee4bf0f6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/428757
Run-TryBot: hopehook <hopehook@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
The lowests fives bits are the kind, and the next five bits are attributes,
not the other way around.
Change-Id: I5e1d13b195b766e99f66bb1227cc7f84e85dc49d
Reviewed-on: https://go-review.googlesource.com/c/go/+/425185
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Change-Id: Ie100a2a6f272b84fa2da6ac7b64452985242d788
Reviewed-on: https://go-review.googlesource.com/c/go/+/428275
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
v.SetIterXXX(i) is semantically identical to v.Set(i.XXX()).
If the latter panics for unexported values, so should the former.
This change may breaking some programs, but the change is justified
under the "Go 1 and the Future of Go Programs" document because
the "library has a bug that violates the specification".
In this case, the "reflect" package does not accurately match
the behavior of the Go language specification.
Also, this API was recently released, so the number of users
who could be depending on this behavior is hopefully lower.
Fixes#54628
Change-Id: If86ede51f286e38093f6697944c089f616525115
Reviewed-on: https://go-review.googlesource.com/c/go/+/425184
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: David Chase <drchase@google.com>
go:notinheap will be replaced by runtime/internal/sys.NotInHeap, and for
longer term, we want to restrict all of its usages inside the runtime
package only.
Updates #46731
Change-Id: I267adc2a19f0dc8a1ed29b5b4aeec1a7dc7318d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/421880
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The current implementation always returns false for non-comparable
values, update the doc to reflect that.
Change-Id: I87f2da408874b0a209c8f51949e3310da15c5904
Reviewed-on: https://go-review.googlesource.com/c/go/+/426195
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: xie cui <523516579@qq.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: hopehook <hopehook@golangcn.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If array element is not interface, array or struct, we just need to
check whether the array element type is comparable.
Change-Id: I1ab94cfa17ae86feb6cd3fbdf878af5a776e7bec
Reviewed-on: https://go-review.googlesource.com/c/go/+/426194
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #46746
Change-Id: I879124974cdb55932cd9d07d3b384d49d5059857
Reviewed-on: https://go-review.googlesource.com/c/go/+/423794
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Fixes#54669
Change-Id: I34cbe729d187437ddeafbaa910af6ed001b2603f
Reviewed-on: https://go-review.googlesource.com/c/go/+/425461
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
If a struct or array is comparable, then we can leverage rtype.equal,
which is almost always faster than what Go reflection can achieve.
As a secondary optimization, pre-compute Value.Len and Value.NumField
outside of the loop conditional.
Performance:
name old time/op new time/op delta
IsZero/ArrayComparable 136ns ± 4% 16ns ± 1% -88.28% (p=0.008 n=5+5)
IsZero/ArrayIncomparable 197ns ±10% 123ns ± 1% -37.74% (p=0.008 n=5+5)
IsZero/StructComparable 26.4ns ± 0% 9.6ns ± 1% -63.68% (p=0.016 n=4+5)
IsZero/StructIncomparable 43.5ns ± 1% 27.8ns ± 1% -36.21% (p=0.008 n=5+5)
The incomparable types gain a performance boost since
they are generally constructed from nested comparable types.
Change-Id: If2c1929f8bb1b5b19306ef0c69f3c95a27d4b60d
Reviewed-on: https://go-review.googlesource.com/c/go/+/411478
Reviewed-by: Dan Kortschak <dan@kortschak.io>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
As CL 422214 did, this CL intends to clean up the rest
unreachable "Continue" after Fatal.
Change-Id: I3b7e1b59bdfccb185e20525ce113e241d277dad3
Reviewed-on: https://go-review.googlesource.com/c/go/+/422514
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: hopehook <hopehook@qq.com>
[This is a retry of CL 407036 + its revert CL 422394. The only
content change is the 1-line change in cmd/internal/obj/objfile.go.]
Read the bitmaps one uintptr at a time instead of one byte at a time.
Performance so far:
Allocation heavy, no retention: ~30% faster in heapBitsSetType
Scan heavy, ~no allocation: ~even in scanobject
Change-Id: I04d899e1dbd23e989e9f552cdc1880318779c14c
Reviewed-on: https://go-review.googlesource.com/c/go/+/422635
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
[this is a retry of CL 407035 + its revert CL 422395. The content is unchanged]
Use just 1 bit per word to record the ptr/nonptr bitmap.
Use word-sized operations to manipulate the bitmap, so we can operate
on up to 64 ptr/nonptr bits at a time.
Use a separate bitmap, one bit per word of the ptr/nonptr bitmap,
to encode a no-more-pointers signal. Since we can check 64 ptr/nonptr
bits at once, knowing the exact last pointer location is not necessary.
As a followon CL, we should make the gcdata bitmap an array of
uintptr instead of an array of byte, so we can load 64 bits of it at once.
Similarly for the processing of gc programs.
Change-Id: Ica5eb622f5b87e647be64f471d67b02732ef8be6
Reviewed-on: https://go-review.googlesource.com/c/go/+/422634
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
The comment claims that reflect users cannot obtain an unsafe.Pointer
without also importing the unsafe package explicitly.
This is no longer true now that the Value.UnsafePointer method
directly returns an unsafe.Pointer.
Change-Id: Ia5bf2e8aead681c8fac5b011129954d075ae5a43
Reviewed-on: https://go-review.googlesource.com/c/go/+/404396
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This reverts commit b589208c8c.
Reason for revert: Bug somewhere in this code, causing wasm and maybe linux/386 to fail.
Change-Id: I5e1e501d839584e0219271bb937e94348f83c11f
Reviewed-on: https://go-review.googlesource.com/c/go/+/422395
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts commit c3833a5543.
Reason for revert: Bug somewhere in this code, causing wasm and maybe linux/386 to fail.
Change-Id: I05f7cfa467598ca0c2c84fd4f752cc4ef117cc51
Reviewed-on: https://go-review.googlesource.com/c/go/+/422394
Run-TryBot: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
So we don't have to duplicate the logic to detect noopt builder in
multiple places.
Based on khr@'s suggestion in CL 422037.
Change-Id: Idb338e8bc08cdf00460574bfc0d2f7018c79bbd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/422038
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Calling TypeOf to initialize variables forces any import of "reflect"
to link in the declared types of "reflect" even if they are unused.
TypeOf operates on Type and which will pull in
all transitive dependencies of Type, which includes Value as well.
Avoid this problem by declaring a rtypeOf function that
directly extracts the *rtype from an interface value
without going through Type as an intermediate type.
For a program that blank imports "reflect",
this reduces the binary size by ~34 KiB.
Updates #54097
Change-Id: I8dc7d8da8fedc48cc0dd842b69f510d17144827e
Reviewed-on: https://go-review.googlesource.com/c/go/+/419757
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Read the bitmaps one uintptr at a time instead of one byte at a time.
Performance so far:
Allocation heavy, no retention: ~30% faster in heapBitsSetType
Scan heavy, ~no allocation: ~even in scanobject
Change-Id: I40d492b50d7f89d1b4261c2de58f6d255fa5e93e
Reviewed-on: https://go-review.googlesource.com/c/go/+/407036
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Use just 1 bit per word to record the ptr/nonptr bitmap.
Use word-sized operations to manipulate the bitmap, so we can operate
on up to 64 ptr/nonptr bits at a time.
Use a separate bitmap, one bit per word of the ptr/nonptr bitmap,
to encode a no-more-pointers signal. Since we can check 64 ptr/nonptr
bits at once, knowing the exact last pointer location is not necessary.
This cleans up the bitmap implementation significantly, which will
hopefully make it faster. TODO: measure
As a followon CL, we should make the gcdata bitmap an array of
uintptr instead of an array of byte, so we can load 64 bits of it at once.
Similarly for the processing of gc programs.
Change-Id: I18151b1876d9543599800dec51e2a1b19df97d49
Reviewed-on: https://go-review.googlesource.com/c/go/+/407035
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Change-Id: Icb552dc7106afbf6bd4bd3660d632f174153f834
Reviewed-on: https://go-review.googlesource.com/c/go/+/408914
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Previously we stole a bit from the field offset to encode whether
a struct field was embedded.
Instead, encode that bit in the name field, where we already have
some unused bits to play with. The bit associates naturally with
the name in any case.
This leaves a full uintptr to specify field offsets. This will make
the fix for #52740 cleaner.
Change-Id: I0bfb85564dc26e8c18101bc8b432f332176d7836
Reviewed-on: https://go-review.googlesource.com/c/go/+/412138
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Daniel Martí
cui fliter
Russ Cox
Cuong Manh Le
David Chase
Ian Lance Taylor
Tobias Klauser
hopehook
Joe Tsai
Michael Anthony Knyszek
Zeke Lu
cuiweixie
Keith Randall
Keith Randall
Koichi Shiraishi