- 16 Mar, 2016 30 commits
-
-
Josh Bleecher Snyder authored
It is unused. Passes toolstash -cmp. Change-Id: I22ae2bb432ce6be377dea43cf018ffccb6e95f37 Reviewed-on: https://go-review.googlesource.com/20698Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently we shrink stacks during STW mark termination because it used to be unsafe to shrink them concurrently. For some programs, this significantly increases pause time: stack shrinking costs ~5ms/MB copied plus 2µs/shrink. Now that we've made it safe to shrink a stack without the world being stopped, shrink them during the concurrent mark phase. This reduces the STW time in the program from issue #12967 by an order of magnitude and brings it from over the 10ms goal to well under: name old 95%ile-markTerm-time new 95%ile-markTerm-time delta Stackshrink-4 23.8ms ±60% 1.80ms ±39% -92.44% (p=0.008 n=5+5) Fixes #12967. This slows down the go1 and garbage benchmarks overall by < 0.5%. name old time/op new time/op delta XBenchGarbage-12 2.48ms ± 1% 2.49ms ± 1% +0.45% (p=0.005 n=25+21) name old time/op new time/op delta BinaryTree17-12 2.93s ± 2% 2.97s ± 2% +1.34% (p=0.002 n=19+20) Fannkuch11-12 2.51s ± 1% 2.59s ± 0% +3.09% (p=0.000 n=18+18) FmtFprintfEmpty-12 51.1ns ± 2% 51.5ns ± 1% ~ (p=0.280 n=20+17) FmtFprintfString-12 175ns ± 1% 169ns ± 1% -3.01% (p=0.000 n=20+20) FmtFprintfInt-12 160ns ± 1% 160ns ± 0% +0.53% (p=0.000 n=20+20) FmtFprintfIntInt-12 265ns ± 0% 266ns ± 1% +0.59% (p=0.000 n=20+20) FmtFprintfPrefixedInt-12 237ns ± 1% 238ns ± 1% +0.44% (p=0.000 n=20+20) FmtFprintfFloat-12 326ns ± 1% 341ns ± 1% +4.55% (p=0.000 n=20+19) FmtManyArgs-12 1.01µs ± 0% 1.02µs ± 0% +0.43% (p=0.000 n=20+19) GobDecode-12 8.41ms ± 1% 8.30ms ± 2% -1.22% (p=0.000 n=20+19) GobEncode-12 6.66ms ± 1% 6.68ms ± 0% +0.30% (p=0.000 n=18+19) Gzip-12 322ms ± 1% 322ms ± 1% ~ (p=1.000 n=20+20) Gunzip-12 42.8ms ± 0% 42.9ms ± 0% ~ (p=0.174 n=20+20) HTTPClientServer-12 69.7µs ± 1% 70.6µs ± 1% +1.20% (p=0.000 n=20+20) JSONEncode-12 16.8ms ± 0% 16.8ms ± 1% ~ (p=0.154 n=19+19) JSONDecode-12 65.1ms ± 0% 65.3ms ± 1% +0.34% (p=0.003 n=20+20) Mandelbrot200-12 3.93ms ± 0% 3.92ms ± 0% ~ (p=0.396 n=19+20) GoParse-12 3.66ms ± 1% 3.65ms ± 1% ~ (p=0.117 n=16+18) RegexpMatchEasy0_32-12 85.0ns ± 2% 85.5ns ± 2% ~ (p=0.143 n=20+20) RegexpMatchEasy0_1K-12 267ns ± 1% 267ns ± 1% ~ (p=0.867 n=20+17) RegexpMatchEasy1_32-12 83.3ns ± 2% 83.8ns ± 1% ~ (p=0.068 n=20+20) RegexpMatchEasy1_1K-12 432ns ± 1% 432ns ± 1% ~ (p=0.804 n=20+19) RegexpMatchMedium_32-12 133ns ± 0% 133ns ± 0% ~ (p=1.000 n=20+20) RegexpMatchMedium_1K-12 40.3µs ± 1% 40.4µs ± 1% ~ (p=0.319 n=20+19) RegexpMatchHard_32-12 2.10µs ± 1% 2.10µs ± 1% ~ (p=0.723 n=20+18) RegexpMatchHard_1K-12 63.0µs ± 0% 63.0µs ± 0% ~ (p=0.158 n=19+17) Revcomp-12 461ms ± 1% 476ms ± 8% +3.29% (p=0.002 n=20+20) Template-12 80.1ms ± 1% 79.3ms ± 1% -1.00% (p=0.000 n=20+20) TimeParse-12 360ns ± 0% 360ns ± 0% ~ (p=0.802 n=18+19) TimeFormat-12 374ns ± 1% 372ns ± 0% -0.77% (p=0.000 n=20+19) [Geo mean] 61.8µs 62.0µs +0.40% Change-Id: Ib60cd46b7a4987e07670eb271d22f6cee5802842 Reviewed-on: https://go-review.googlesource.com/20044Reviewed-by:
Keith Randall <khr@golang.org>
-
Austin Clements authored
We're about to add another root marking job that needs to happen only during the first markroot pass (whether that's concurrent or STW), just like finalizer scanning. Rather than introducing another flag that has the same value as finalizersDone, just rename finalizersDone to markrootDone. Change-Id: I535356c6ea1f3734cb5b6add264cb7bf48de95e8 Reviewed-on: https://go-review.googlesource.com/20043Reviewed-by:
Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently shinkstack is only safe during STW because it adjusts channel-related stack pointers and moves send/receive stack slots without synchronizing with the channel code. Make it safe to use when the world isn't stopped by: 1) Locking all channels the G is blocked on while adjusting the sudogs and copying the area of the stack that may contain send/receive slots. 2) For any stack frames that may contain send/receive slot, using an atomic CAS to adjust pointers to prevent races between adjusting a pointer in a receive slot and a concurrent send writing to that receive slot. In principle, the synchronization could be finer-grained. For example, we considered synchronizing around the sudogs, which would allow channel operations involving other Gs to continue if the G being shrunk was far enough down the send/receive queue. However, using the channel lock means no additional locks are necessary in the channel code. Furthermore, the stack shrinking code holds the channel lock for a very short time (much less than the time required to shrink the stack). This does not yet make stack shrinking concurrent; it merely makes doing so safe. This has negligible effect on the go1 and garbage benchmarks. For #12967. Change-Id: Ia49df3a8a7be4b36e365aac4155a2416b94b988c Reviewed-on: https://go-review.googlesource.com/20042Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Austin Clements <austin@google.com>
-
Austin Clements authored
Currently, locking a G's stack by setting its status to _Gcopystack or _Gscan is unordered with respect to channel locks. However, when we make stack shrinking concurrent, stack shrinking will need to lock the G and then acquire channel locks, which imposes an order on these. Document this lock ordering and fix closechan to respect it. Everything else already happens to respect it. For #12967. Change-Id: I4dd02675efffb3e7daa5285cf75bf24f987d90d4 Reviewed-on: https://go-review.googlesource.com/20041Reviewed-by:
Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently sudog.elem is never accessed concurrently, so in several cases we drop the channel lock just before reading/writing the sent/received value from/to sudog.elem. However, concurrent stack shrinking is going to have to adjust sudog.elem to point to the new stack, which means it needs a way to synchronize with accesses to sudog.elem. Hence, add sudog.elem to the fields protected by hchan.lock and scoot the unlocks down past the uses of sudog.elem. While we're here, better document the channel synchronization rules. For #12967. Change-Id: I3ad0ca71f0a74b0716c261aef21b2f7f13f74917 Reviewed-on: https://go-review.googlesource.com/20040Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
With concurrent stack shrinking, the stack can move the instant after a G enters _Gwaiting. There are only two places that put a G into _Gwaiting: gopark and newstack. We fixed uses of gopark. This commit fixes newstack by simplifying its G transitions and, in particular, eliminating or narrowing the transient _Gwaiting states it passes through so it's clear nothing in the G is accessed while in _Gwaiting. For #12967. Change-Id: I2440ead411d2bc61beb1e2ab020ebe3cb3481af9 Reviewed-on: https://go-review.googlesource.com/20039Reviewed-by:
Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
gopark calls the unlock function after setting the G to _Gwaiting. This means it's generally unsafe to access the G's stack from the unlock function because the G may start running on another P. Once we start shrinking stacks concurrently, a stack shrink could also move the stack the moment after it enters _Gwaiting and before the unlock function is called. Document this restriction and fix the two places where we currently violate it. This is unlikely to be a problem in practice for these two places right now, but they're already skating on thin ice. For example, the following sequence could in principle cause corruption, deadlock, or a panic in the select code: On M1/P1: 1. G1 selects on channels A and B. 2. selectgoImpl calls gopark. 3. gopark puts G1 in _Gwaiting. 4. gopark calls selparkcommit. 5. selparkcommit releases the lock on channel A. On M2/P2: 6. G2 sends to channel A. 7. The send puts G1 in _Grunnable and puts it on P2's run queue. 8. The scheduler runs, selects G1, puts it in _Grunning, and resumes G1. 9. On G1, the sellock immediately following the gopark gets called. 10. sellock grows and moves the stack. On M1/P1: 11. selparkcommit continues to scan the lock order for the next channel to unlock, but it's now reading from a freed (and possibly reused) stack. This shouldn't happen in practice because step 10 isn't the first call to sellock, so the stack should already be big enough. However, once we start shrinking stacks concurrently, this reasoning won't work any more. For #12967. Change-Id: I3660c5be37e5be9f87433cb8141bdfdf37fadc4c Reviewed-on: https://go-review.googlesource.com/20038Reviewed-by:
Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently the g.waiting list created by a select is in poll order. However, nothing depends on this, and we're going to need access to the channel lock order in other places shortly, so modify select to put the waiting list in channel lock order. For #12967. Change-Id: If0d38816216ecbb37a36624d9b25dd96e0a775ec Reviewed-on: https://go-review.googlesource.com/20037Reviewed-by:
Rick Hudson <rlh@golang.org> Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Austin Clements <austin@google.com>
-
Austin Clements authored
Currently the select lock order is a []*hchan. We're going to need to refer to things other than the channel itself in lock order shortly, so switch this to a []uint16 of indexes into the select cases. This parallels the existing representation for the poll order. Change-Id: I89262223fe20b4ddf5321592655ba9eac489cda1 Reviewed-on: https://go-review.googlesource.com/20036Reviewed-by:
Rick Hudson <rlh@golang.org> Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Given a G, there's currently no way to find the channel it's blocking on. We'll need this information to fix a (probably theoretical) bug in select and to implement concurrent stack shrinking, so record the channel in the sudog. For #12967. Change-Id: If8fb63a140f1d07175818824d08c0ebeec2bdf66 Reviewed-on: https://go-review.googlesource.com/20035Reviewed-by:
Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
gcMarkRootCheck is too expensive to do during mark termination. However, since it's a useful check and it complements checkmark mode nicely, enable it during mark termination is checkmark is enabled. Change-Id: Icd9039e85e6e9d22747454441b50f1cdd1412202 Reviewed-on: https://go-review.googlesource.com/20663Reviewed-by:
Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
I was wondering why cmd/go includes the HTTP server implementations. Dumping the linker's deadcode dependency graph into a file and doing some graph analysis, I found that the only reason cmd/go included an HTTP server was because the maxBytesReader type (used by both the HTTP transport & HTTP server) did a static type assertion to an HTTP server type. Changing it to a interface type assertion reduces the size of cmd/go by 533KB (5.2%) On linux/amd64, cmd/go goes from 10549200 to 10002624 bytes. Add a test too so this doesn't regress. The test uses cmd/go as the binary to test (a binary which needs the HTTP client but not the HTTP server), but this change and test are equally applicable to any such program. Change-Id: I93865f43ec03b06d09241fbd9ea381817c2909c5 Reviewed-on: https://go-review.googlesource.com/20763Reviewed-by:
Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
Step 2 of stream-lining parameter parsing - do parameter validity checks in parser - two passes instead of multiple (and theoretically quadratic) passes when checking parameters - removes the need for OKEY and some ONONAME nodes in those passes This removes allocation of ~123K OKEY (incl. some ONONAME) nodes out of a total of ~10M allocated nodes when running make.bash, or a reduction of the number of alloacted nodes by ~1.2%. Change-Id: I4a8ec578d0ee2a7b99892ac6b92e56f8e0415f03 Reviewed-on: https://go-review.googlesource.com/20748Reviewed-by:
Matthew Dempsky <mdempsky@google.com> Run-TryBot: Robert Griesemer <gri@golang.org>
-
Alan Donovan authored
Change-Id: I049d2596fe8ce0e93391599f5c224779fd8e316f Reviewed-on: https://go-review.googlesource.com/20761Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
Step 1 of streamlining parameter parsing. Change-Id: If9fd38295ccc08aafc7f1d26188d0926dd73058b Reviewed-on: https://go-review.googlesource.com/20747Reviewed-by:
Matthew Dempsky <mdempsky@google.com> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Todd Neal authored
Fixes #14825 Change-Id: Ib44d80579a55c15d75ea2ad1ef54efa6ca66a9a6 Reviewed-on: https://go-review.googlesource.com/20745 Run-TryBot: Todd Neal <todd@tneal.org> Reviewed-by:
Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Martin Möhrmann authored
Use The fmt internal buffer for character formatting instead of the pp Printer rune decoding buffer. Uses an uint64 instead of int64 argument to fmt_c and fmt_qc for easier range checks since no valid runes are represented by negative numbers or are above 0x10ffff. Add range checks to fmt_c and fmt_qc to guarantee that a RuneError character is returned by the functions for any invalid code point in range uint64. For invalid code points in range utf8.MaxRune the used utf8 and strconv functions already return a RuneError. Change-Id: I9772f804dfcd79c3826fa7f6c5ebfbf4b5304a51 Reviewed-on: https://go-review.googlesource.com/20373 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Martin Möhrmann authored
Remove check for %p and %T in printValue. These verbs are not recursive and are handled already in printArg which is called on any argument before printValue. Format the type string for %T directly instead of invoking the more complex printArg with %s on the type string. Decouple the %T tests from variables declared in scan_test.go. Change-Id: Ibd51566bd4cc1a260ce6d052f36382ed05020b48 Reviewed-on: https://go-review.googlesource.com/20622 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Aliaksandr Valialkin authored
Fixes #14664 Change-Id: I8bda2435857772f590859808904c48d768b87d46 Reviewed-on: https://go-review.googlesource.com/20254 Run-TryBot: Rob Pike <r@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Rob Pike authored
The Join test was doing something remarkable and unnecessary instead of just using ... on a slice. Maybe it was an editing relic. Fix it by deleting the monstrosity. Change-Id: I5b90c6d539d334a9c27e57d26dacd831721cfcfe Reviewed-on: https://go-review.googlesource.com/20727Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Martin Möhrmann authored
Do a reset of the fmt flags before printing the extra argument error message to prevent a malformed printing of extra arguments. Regroup tests for extra argument error strings. Change-Id: Ifd97f5ca36f6c97ed5a380d975cf154d17997d3f Reviewed-on: https://go-review.googlesource.com/20571 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Mikio Hara authored
This change filters out destination addresses by address family when source address is specified to avoid running Dial operation with wrong addressing scopes. Fixes #11837. Change-Id: I10b7a1fa325add2cd8ed58f105d527700a10d342 Reviewed-on: https://go-review.googlesource.com/20586Reviewed-by:
Paul Marks <pmarks@google.com>
-
Mikio Hara authored
On the latest darwin kernels, kevent in runtime-integrated network poller sometimes reports SYN-SENT state sockets as ESTABLISHED ones, though it's still unclear what's the root cause. This change prevents such spurious notifications by additional connect system calls. Fixes #14548. Change-Id: Ie29788e38ca735ca77259befeba3229d6a30ac52 Reviewed-on: https://go-review.googlesource.com/20468 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
This change consolidates functions and methods related to UnixAddr, UnixConn and UnixListener for maintenance purpose, especially for documentation. The followup changes will update comments and examples. Updates #10624. Change-Id: I372d152099ac10956284e6b3863d7e4d9fe5c8e9 Reviewed-on: https://go-review.googlesource.com/20125 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
This change consolidates functions and methods related to IPAddr and IPConn for maintenance purpose, especially for documentation. The followup changes will update comments and examples. Updates #10624. Change-Id: Ia5146f234225704a3c0b6459e1903e56a7b68134 Reviewed-on: https://go-review.googlesource.com/20124 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
This change consolidates functions and methods related to UDPAddr and UDPConn for maintenance purpose, especially for documentation. The followup changes will update comments and examples. Updates #10624. Change-Id: Idfe9be8ea46ade1111b0ae176862b2048eafc7be Reviewed-on: https://go-review.googlesource.com/20120 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
Change-Id: I5dbcdf0ee0b46b760b2a7decb1d937aac2a6fa8d Reviewed-on: https://go-review.googlesource.com/20585 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Todd Neal authored
Change-Id: I01c000ff3f6dc6b0ed691e289eeef0fa61500337 Reviewed-on: https://go-review.googlesource.com/20744Reviewed-by:
Keith Randall <khr@golang.org>
-
Martin Möhrmann authored
Use constants instead of dynamically computed values to determine the bit sizes of types similar to how strconv and other packages directly compute these sizes. Move these constants near the code that uses them. Change-Id: I78d113b7e697466097e32653975df5990380c2c1 Reviewed-on: https://go-review.googlesource.com/20514 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
- 15 Mar, 2016 10 commits
-
-
Dave Day authored
This change also refactors SplitHostPort to avoid using gotos and naked returns. Fixes #14827 Change-Id: I4dca528936757fd06da76c23af8a0f6175bbedd1 Reviewed-on: https://go-review.googlesource.com/20726Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Todd Neal authored
Change-Id: Ieefeceea40bd29657fd519368b0920dad8443844 Reviewed-on: https://go-review.googlesource.com/20712 Run-TryBot: Todd Neal <todd@tneal.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Keith Randall authored
They've been on for a few weeks of general use and nothing has tripped up on them yet. Makes the compiler ~18% faster. Change-Id: I42d7bbc0581597f9cf4fb28989847814c81b08a2 Reviewed-on: https://go-review.googlesource.com/20741Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Matloob authored
The new link is https://golang.org/s/go15heapdump. Change-Id: Ifcaf8572bfe815ffaa78442a1991f6e20e990a50 Reviewed-on: https://go-review.googlesource.com/20740Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Matthew Dempsky authored
The obj.Fmt* values are only used by gc/fmt.go, so just move them there. Also, add comments documenting the correspondance between FmtFoo names and their flag characters to make understanding the existing documentation slightly less confusing. While here, add a new FmtFlag named type to represent these values. Change-Id: I9631214b892557d094823f1ac575d0c43a84007b Reviewed-on: https://go-review.googlesource.com/20717 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Wedson Almeida Filho authored
Change Cond implementation to use a notification list such that waiters can first register for a notification, release the lock, then actually wait. Signalers never have to park anymore. This is intended to address an issue in the previous implementation where Broadcast could fail to signal all waiters. Results of the existing benchmark are below. Original New Diff BenchmarkCond1-48 2000000 745 ns/op 755 +1.3% BenchmarkCond2-48 1000000 1545 ns/op 1532 -0.8% BenchmarkCond4-48 300000 3833 ns/op 3896 +1.6% BenchmarkCond8-48 200000 10049 ns/op 10257 +2.1% BenchmarkCond16-48 100000 21123 ns/op 21236 +0.5% BenchmarkCond32-48 30000 40393 ns/op 41097 +1.7% Fixes #14064 Change-Id: I083466d61593a791a034df61f5305adfb8f1c7f9 Reviewed-on: https://go-review.googlesource.com/18892Reviewed-by:
Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
Austin Clements <austin@google.com> Run-TryBot: Caleb Spare <cespare@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Caleb Spare authored
While we're at it, add tests for EncodedLen and DecodedLen. Fixes #14803. Change-Id: I200c72cf11c51669b8d9f70c6e57ece359f7ae61 Reviewed-on: https://go-review.googlesource.com/20649Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
Change-Id: I34cdc9cb3d32e86ff3a57db0012326c39cd55670 Reviewed-on: https://go-review.googlesource.com/20718Reviewed-by:
Robert Griesemer <gri@golang.org>
-
David Crawshaw authored
The type information for a method includes two variants: a func without the receiver, and a func with the receiver as the first parameter. The former is used as part of the dynamic interface checks, but the latter is only returned as a type in the reflect.Method struct. Instead of computing it at compile time, construct it at run time with reflect.FuncOf. Using cl/20701 as a baseline, cmd/go: -480KB, (4.4%) jujud: -5.6MB, (7.8%) For #6853. Change-Id: I1b8c73f3ab894735f53d00cb9c0b506d84d54e92 Reviewed-on: https://go-review.googlesource.com/20709 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Matthew Dempsky authored
All of a struct's fields have to fit into memory anyway, so index them with int instead of int64. This also makes it nicer for cmd/compile/internal/gc to reuse the same NumFields function. Change-Id: I210be804a0c33370ec9977414918c02c675b0fbe Reviewed-on: https://go-review.googlesource.com/20691Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-