b66bc0a9d5
Method signatures can introduce a significant number of edges into the type graph. One can imagine a generic type with many methods, each of which may use other instantiated types, etc. For performance, when type checking generic code, we should avoid unnecessary instantiation of methods wherever possible. This CL achieves this by making method instantiation lazy at the individual method level. It abstracts method access into a methodList type, which may be either eager or lazy. In the lazy case, methods are only instantiated when they are accessed via the Named.Method, MethodSet, or LookupFieldOrMethod APIs. Factoring out a methodList type makes it easier to verify that we're not leaking the methods slice anywhere, and as a side benefit reduces the size of *Named types in the case where there are no methods. The effective memory footprint of Named types with methods increases by a pointer (to hold the slice of guards), and the footprint of instantiated named types increases additionally by a sync.Once per method. We estimate that this memory increase is more than offset by the reduction in the number of instantiated methods. This also simplifies the code. Previously we had to work around the fact that named type expansion could occur before all signatures were set-up, by stashing the instantiated receiver into a partially filled-out *Func. With fully lazy methods, we can rely on the invariant that any use of methods in valid code can only occur after all signatures can be type checked. This means that we can fully instantiate the *Func, and don't need to deal with partially instantiated stubs. Finally, this CL fixes a bug (issue #50619), where traversing Method->Receiver Type->Method did not get us back where we started. This is fixed by not instantiating a new method if t is already the receiver base of the original method. A test is added to explicitly verify the invariant above, and more test cases are added for the behavior of Info with respect to generic code. Fixes #50619 Change-Id: I5b6d2bdc4404c9f5dcb583a29cb64e8af9794c54 Reviewed-on: https://go-review.googlesource.com/c/go/+/380499 Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> |
||
|---|---|---|
| .github | ||
| api | ||
| doc | ||
| lib/time | ||
| misc | ||
| src | ||
| test | ||
| .gitattributes | ||
| .gitignore | ||
| AUTHORS | ||
| CONTRIBUTING.md | ||
| CONTRIBUTORS | ||
| LICENSE | ||
| PATENTS | ||
| README.md | ||
| SECURITY.md | ||
| codereview.cfg | ||
README.md
The Go Programming Language
Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.
Gopher image by Renee French, licensed under Creative Commons 3.0 Attributions license.
Our canonical Git repository is located at https://go.googlesource.com/go. There is a mirror of the repository at https://github.com/golang/go.
Unless otherwise noted, the Go source files are distributed under the BSD-style license found in the LICENSE file.
Download and Install
Binary Distributions
Official binary distributions are available at https://golang.org/dl/.
After downloading a binary release, visit https://golang.org/doc/install for installation instructions.
Install From Source
If a binary distribution is not available for your combination of operating system and architecture, visit https://golang.org/doc/install/source for source installation instructions.
Contributing
Go is the work of thousands of contributors. We appreciate your help!
To contribute, please read the contribution guidelines at https://golang.org/doc/contribute.
Note that the Go project uses the issue tracker for bug reports and proposals only. See https://golang.org/wiki/Questions for a list of places to ask questions about the Go language.