- 22 May, 2019 5 commits
-
-
Russ Cox authored
Shorten some of the longest tests that run during all.bash. Removes 7r 50u 21s from all.bash. After this change, all.bash is under 5 minutes again on my laptop. For #26473. Change-Id: Ie0460aa935808d65460408feaed210fbaa1d5d79 Reviewed-on: https://go-review.googlesource.com/c/go/+/177559 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Each different file that does import "C" must be compiled and analyzed separately by cgo. Having fewer files import "C" reduces the cost of building the test. This is especially important because this test is built and run four different times (with different settings) during all.bash. go test -c in this directory used to take over 20 seconds on my laptop. Now it takes under 5 seconds. Removes 23.4r 29.0u 21.5s from all.bash. For #26473. Change-Id: Ie7cb7b0d9d6138ebd2eb548d0d8ea6e409ae10b9 Reviewed-on: https://go-review.googlesource.com/c/go/+/177558 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Keith Randall authored
First, remove the randomization of initialization order. Then, revert to source code order instead of sorted package path order. This restores the behavior that was in 1.12. A larger change which will implement the suggestion in #31636 will wait for 1.14. It's too complicated for 1.13 at this point (it has tricky interactions with plugins). Fixes #31636 Change-Id: I35b48e8cc21cf9f93c0973edd9193d2eac197628 Reviewed-on: https://go-review.googlesource.com/c/go/+/178297 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Keegan Carruthers-Smith authored
If the char class is 0x0-0x10ffff we mistakenly would String that to `[^]`, which is not a valid regex. Fixes #31807 Change-Id: I9ceeaddc28b67b8e1de12b6703bcb124cc784556 Reviewed-on: https://go-review.googlesource.com/c/go/+/175679Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Damien Neil authored
The Wrapper type no longer exists. Change-Id: I21051f26c6722a957295819f2f385f2bbd0db355 Reviewed-on: https://go-review.googlesource.com/c/go/+/177618Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 21 May, 2019 10 commits
-
-
Filippo Valsorda authored
Fixes #31267 Change-Id: I91e4aa8cf9d797689cb9612d0fe3bf1bb3ad15a6 Reviewed-on: https://go-review.googlesource.com/c/go/+/178177Reviewed-by: Keith Randall <khr@golang.org>
-
Russ Cox authored
Gerrit is complaining about pushes that affect these files and forcing people to use -o nokeycheck, which defeats the point of the check. Hide the keys from this kind of scan by marking them explicitly as testing keys. This is a little annoying but better than training everyone who ever edits one of these test files to reflexively override the Gerrit check. The only remaining keys explicitly marked as private instead of testing are in examples, and there's not much to do about those. Hopefully they are not edited as much. Change-Id: I4431592b5266cb39fe6a80b40e742d97da803a0b Reviewed-on: https://go-review.googlesource.com/c/go/+/178178 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Build a single binary containing all the TestPointerChecks instead of building many small binaries, each with its own cgo+compile+link invocation. This cuts 'go test -run=TestPointerChecks' from 6.7r 35.5u 26.1s to 2.1r 2.1u 1.4s. Move as many cgo checks as possible into fewer test files for TestReportsTypeErrors too. This cuts 'go test -run=TestReportsTypeErrors' from 2.1r 6.7u 6.7s to 1.5r 2.5u 2.5s. After this change, all.bash runs in ~4:30 on my laptop. For #26473. Change-Id: I3787448b03689a1f62dd810957ab6013bb75582f Reviewed-on: https://go-review.googlesource.com/c/go/+/177599 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Cuts api test time from 12.7r 26.2u 14.2s to 7.5r 12.1u 2.2s. After this change, all.bash runs in ~4:36 on my laptop. For #26473. Change-Id: I4211e6afcd7ab61a4ed2c9a2aa5ac1ea04982695 Reviewed-on: https://go-review.googlesource.com/c/go/+/177597 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
LE Manh Cuong authored
typecheck type alias always replaces the original definition of the symbol. This is wrong behavior because if the symbol's definition is replaced by a local type alias, it ends up being written to compiled file as an alias, instead of the original type. To fix, only replace the definition of symbol with global type alias. Fixes #31959 Change-Id: Id85a15e8a9d6a4b06727e655a95dc81e63df633a Reviewed-on: https://go-review.googlesource.com/c/go/+/177378 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Caleb Spare authored
Fixes #31896 Change-Id: I228a809568cd37c599987f9f1e99df5c229e6c9b Reviewed-on: https://go-review.googlesource.com/c/go/+/176112 Run-TryBot: Caleb Spare <cespare@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
LE Manh Cuong authored
Change-Id: Ie299a5eca6f6a7c5a37c00ff0de7ce322450375b Reviewed-on: https://go-review.googlesource.com/c/go/+/178123Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Eduard Urbach authored
This change modifies Go to include image/webp as a built-in mime type for the .webp file extension. Change-Id: Id46d34fac8cc859ddd69aa8669294815654214f8 GitHub-Last-Rev: f191e1c325126e2caeb3123c912131ce5236542b GitHub-Pull-Request: golang/go#32157 Reviewed-on: https://go-review.googlesource.com/c/go/+/178317Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
The test/codegen tests check all architectures mentioned in the test file, but this requires building at least the runtime for that architecture. This CL changes the test to only check the local architecture, leaving checking of other architectures to the relevant builders, as usual. This cuts 'go run run.go codegen' by 12r 78u 21s. After this change, all.bash runs in ~4:40 on my laptop. For #26473. Change-Id: Ia0354d1aff2df2949f838528c8171410bc42dc8b Reviewed-on: https://go-review.googlesource.com/c/go/+/177577 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
LE Manh Cuong authored
Both types.Sym and obj.LSym have the field Name, and that field is widely used in compiler source. It can lead to confusion that when to use which one. So, adding documentation for clarifying the difference between them, eliminate the confusion, or at least, make the code which use them clearer for the reader. See https://github.com/golang/go/issues/31252#issuecomment-481929174 Change-Id: I31f7fc6e4de4cf68f67ab2e3a385a7f451c796f5 Reviewed-on: https://go-review.googlesource.com/c/go/+/175019Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
- 20 May, 2019 11 commits
-
-
Jay Conrod authored
Fixes #32037 Change-Id: I696fe2029e383746252f37fe8d30df71b5ac8a6c Reviewed-on: https://go-review.googlesource.com/c/go/+/177677 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
adarsh ravichandran authored
Change-Id: Id87db9bed5e8715d554c1bf95c063d7d0a03c3e9 Reviewed-on: https://go-review.googlesource.com/c/go/+/178117 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Keith Randall authored
That way we will never have to look up the file/line for the frame that's next to be returned when the user stops calling Next. For the benchmark from #32093: name old time/op new time/op delta Helper-4 948ns ± 1% 836ns ± 3% -11.89% (p=0.000 n=9+9) (#32093 was fixed with a more specific, and better, fix, but this fix is much more general.) Change-Id: I89e796f80c9706706d8d8b30eb14be3a8a442846 Reviewed-on: https://go-review.googlesource.com/c/go/+/178077 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Anthony Knyszek authored
Currently, this test allocates many objects and relies on heap-growth scavenging to happen unconditionally on heap-growth. However with the new pacing system for the scavenging, this is no longer true and the test is flaky. So, this change overhauls TestPhysicalMemoryUtilization to check the same aspect of the runtime, but in a much more robust way. Firstly, it sets up a much more constrained scenario: only 5 objects are allocated total with a maximum worst-case (i.e. the test fails) memory footprint of about 16 MiB. The test is now aware that scavenging will only happen if the heap growth causes us to push way past our scavenge goal, which is based on the heap goal. So, it makes the holes in the test much bigger and the actual retained allocations much smaller to keep the heap goal at the heap's minimum size. It does this twice to create exactly two unscavenged holes. Because the ratio between the size of the "saved" objects and the "condemned" object is so small, two holes are sufficient to create a consistent test. Then, the test allocates one enormous object (the size of the 4 other objects allocated, combined) with the intent that heap-growth scavenging should kick in and scavenge the holes. The heap goal will rise after this object is allocated, so it's very important we do all the scavenging in a single allocation that exceeds the heap goal because otherwise the rising heap goal could foil our test. Finally, we check memory use relative to HeapAlloc as before. Since the runtime should scavenge the entirety of the remaining holes, theoretically there should be no more free and unscavenged memory. However due to other allocations that may happen during the test we may still see unscavenged memory, so we need to have some threshold. We keep the current 10% threshold which, while arbitrary, is very conservative and should easily account for any other allocations the test makes. Before, we also had to ensure the allocations we were making looked large relative to the size of a heap arena since newly-mapped memory was considered unscavenged, and so that could significantly skew the test. However, thanks to the fix for #32012 we were able to reduce memory use to 16 MiB in the worst case. Fixes #32010. Change-Id: Ia38130481e292f581da7fa3289c98c99dc5394ed Reviewed-on: https://go-review.googlesource.com/c/go/+/177237Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Alex Myasoedov authored
Fixes #32145 Change-Id: If4c9dd3a2af748974141ad6e571f80efcbaad772 Reviewed-on: https://go-review.googlesource.com/c/go/+/177899Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Shulhan authored
If we look at the issues in the past releases that are related to go command that involved modules, its usually mention or ask about the value of GO111MODULE, either in separate line or in separate comment. There are quite long time range before GO111MODULE will be removed (unused). The next release is still default to auto [1], and until Go 1.13 unsupported (two releases after that) there is about one and half years after that. Since the change is not that big (one line) [2], maybe temporary adding it to "go env" give more clarity and benefit in issue reporting rather than not. [1] https://github.com/golang/go/issues/31857 Fixes #29656 Change-Id: I609ad6664774018e4f4147ec6158485172968e16 Reviewed-on: https://go-review.googlesource.com/c/go/+/176837 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
LE Manh Cuong authored
CL 14870 added internal/race to factor out duplicated race thunks, we should use it. No signification changes in compile time and compile binary size. Change-Id: I786af44dd5bb0f4ab6709432eeb603f27a5b6c63 Reviewed-on: https://go-review.googlesource.com/c/go/+/178118 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
The "After it is called, changing rw.Header will not affect rw.HeaderMap" claim predates the Result method which changed how the Recorder should be used. Fixes #32144 Fixes #32136 Change-Id: I95bdfa5ac489ce7b0202824bb5663f4da188e8a7 Reviewed-on: https://go-review.googlesource.com/c/go/+/178058Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-
Brad Fitzpatrick authored
Change-Id: I357669d8c9bc004031b17f057803c9b152edefee Reviewed-on: https://go-review.googlesource.com/c/go/+/178057Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
taoyuanyuan authored
The chunks that were referenced by fd.iovecs would not be GC. Change-Id: I7bfcb91a3fef57a4a1861168e9cd3ab55ce1334e GitHub-Last-Rev: e0b7f68447441fd89ed1a6e8aa37e2084fd863b2 GitHub-Pull-Request: golang/go#32138 Reviewed-on: https://go-review.googlesource.com/c/go/+/178037 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
smasher164 authored
Make the extended precision add-with-carry and sub-with-carry operations take a constant amount of time to execute, regardless of input. name old time/op new time/op delta Add-4 1.16ns ±11% 1.51ns ± 5% +30.52% (p=0.008 n=5+5) Add32-4 1.08ns ± 0% 1.03ns ± 1% -4.86% (p=0.029 n=4+4) Add64-4 1.09ns ± 1% 1.95ns ± 3% +79.23% (p=0.008 n=5+5) Add64multiple-4 4.03ns ± 1% 4.55ns ±11% +13.07% (p=0.008 n=5+5) Sub-4 1.08ns ± 1% 1.50ns ± 0% +38.17% (p=0.016 n=5+4) Sub32-4 1.09ns ± 2% 1.53ns ±10% +40.26% (p=0.008 n=5+5) Sub64-4 1.10ns ± 1% 1.47ns ± 1% +33.39% (p=0.008 n=5+5) Sub64multiple-4 4.30ns ± 2% 4.08ns ± 4% -5.07% (p=0.032 n=5+5) Fixes #31267 Change-Id: I1824b1b3ab8f09902ce8b5fef84ce2fdb8847ed9 Reviewed-on: https://go-review.googlesource.com/c/go/+/170758Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 17 May, 2019 12 commits
-
-
Keith Randall authored
callerName requested 2 PCs from Callers, and that causes both to be looked up in the file/line mapping. We really only need to do the work for one PC. (And in fact the caller doesn't need file/line at all, but the Callers API can't express that.) We used to request 2 PCs because in 1.11 and earlier we stored an inline skip count in the second entry. That's not necessary any more (as of 1.12). Fixes #32093 Change-Id: I7b272626ef6496e848ee8af388cdaafd2556857b Reviewed-on: https://go-review.googlesource.com/c/go/+/177858 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Caleb Spare <cespare@gmail.com>
-
Josh Bleecher Snyder authored
name old alloc/op new alloc/op delta Template 37.1MB ± 0% 36.8MB ± 0% -0.57% (p=0.008 n=5+5) Unicode 28.1MB ± 0% 28.1MB ± 0% -0.07% (p=0.008 n=5+5) GoTypes 125MB ± 0% 124MB ± 0% -0.61% (p=0.008 n=5+5) Compiler 571MB ± 0% 568MB ± 0% -0.60% (p=0.008 n=5+5) SSA 1.88GB ± 0% 1.86GB ± 0% -0.82% (p=0.008 n=5+5) Flate 22.9MB ± 0% 22.8MB ± 0% -0.59% (p=0.008 n=5+5) GoParser 27.5MB ± 0% 27.3MB ± 0% -0.53% (p=0.008 n=5+5) Reflect 79.8MB ± 0% 79.5MB ± 0% -0.40% (p=0.008 n=5+5) Tar 34.9MB ± 0% 34.7MB ± 0% -0.44% (p=0.008 n=5+5) XML 45.7MB ± 0% 45.4MB ± 0% -0.58% (p=0.008 n=5+5) [Geo mean] 80.3MB 79.9MB -0.52% name old allocs/op new allocs/op delta Template 380k ± 0% 378k ± 0% -0.57% (p=0.008 n=5+5) Unicode 340k ± 0% 340k ± 0% -0.08% (p=0.008 n=5+5) GoTypes 1.36M ± 0% 1.36M ± 0% -0.44% (p=0.008 n=5+5) Compiler 5.52M ± 0% 5.49M ± 0% -0.45% (p=0.008 n=5+5) SSA 17.6M ± 0% 17.5M ± 0% -0.42% (p=0.008 n=5+5) Flate 235k ± 0% 234k ± 0% -0.65% (p=0.008 n=5+5) GoParser 302k ± 0% 300k ± 0% -0.70% (p=0.008 n=5+5) Reflect 982k ± 0% 978k ± 0% -0.40% (p=0.008 n=5+5) Tar 353k ± 0% 351k ± 0% -0.53% (p=0.008 n=5+5) XML 437k ± 0% 435k ± 0% -0.48% (p=0.008 n=5+5) [Geo mean] 844k 840k -0.47% Updates #27739 Change-Id: I5d533013270cbbd7c0bad1b43da96c8499be76f5 Reviewed-on: https://go-review.googlesource.com/c/go/+/177917 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Filippo Valsorda authored
In TLS 1.3 session tickets are delivered after the handshake, and it looks like now the Google servers wait until the first flight of data to send them (or our timeout is too low). Cause some data to be sent so we can avoid the guessing game. Fixes #32090 Change-Id: I54af4acb3a89cc70c9e14a5dfe18a44c29a841a7 Reviewed-on: https://go-review.googlesource.com/c/go/+/177877Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Dmitri Shuralyov authored
The motivation for doing so is to avoid making inaccurate claims. Logging may not go to os.Stderr if anyone overrides the log package's default output via https://godoc.org/log#SetOutput. Saying that the standard logger is used should be sufficient to explain the behavior, and users can infer that os.Stderr is used by default, unless it's changed. This change is the same as what was applied to http.Server.ErrorLog documentation in CL 53950. Change-Id: I32873fc548ceee573f8616b4d49b8a8b98881803 Reviewed-on: https://go-review.googlesource.com/c/go/+/176817Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Jay Conrod authored
When we downgrade a module (using 'go get m@none' or similar), we exclude versions of other modules that depend on it. We'll try previous versions (in the "versions" list returned by the proxy or in codeRepo.Versions for vcs) until we find a version that doesn't require an excluded module version. If older versions of a module are broken for some reason, mvs.Downgrade currently panics. With this change, we ignore versions with errors during downgrade. A frequent cause of this is incompatible v2+ versions. These are common if a repository tagged v2.0.0 before migrating to modules, then tagged v2.0.1 with a go.mod file later. v2.0.0 is incorrectly considered part of the v2 module. Fixes #31942 Change-Id: Icaa75c5c93f73f18a400c22f18a8cc603aa4011a Reviewed-on: https://go-review.googlesource.com/c/go/+/177337 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Jean de Klerk authored
The current example illustrates using As when the error is able to be interpreted as an os.PathError, but elides the "else" case. This CL adds the small extra else case to make it clear that it's not safe to assume As will return true. This CL also squash the err instantiation and the err nil check into one line for brevity. Change-Id: I3d3ab483ffb38fb2788d0498b3f03229a87dd7c3 Reviewed-on: https://go-review.googlesource.com/c/go/+/177717Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Filippo Valsorda authored
Support for Ed25519 certificates was added in CL 175478, this wires them up into the TLS stack according to RFC 8422 (TLS 1.2) and RFC 8446 (TLS 1.3). RFC 8422 also specifies support for TLS 1.0 and 1.1, and I initially implemented that, but even OpenSSL doesn't take the complexity, so I just dropped it. It would have required keeping a buffer of the handshake transcript in order to do the direct Ed25519 signatures. We effectively need to support TLS 1.2 because it shares ClientHello signature algorithms with TLS 1.3. While at it, reordered the advertised signature algorithms in the rough order we would want to use them, also based on what curves have fast constant-time implementations. Client and client auth tests changed because of the change in advertised signature algorithms in ClientHello and CertificateRequest. Fixes #25355 Change-Id: I9fdd839afde4fd6b13fcbc5cc7017fd8c35085ee Reviewed-on: https://go-review.googlesource.com/c/go/+/177698 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
-
Joel Sing authored
A timespec on netbsd/amd64 is int64/int64, not int64/int32. This bug appears to have been introduced in 7777bac6. Spotted by Cherry Zhang while reviewing https://go-review.googlesource.com/c/go/+/177120. Change-Id: I163c55d926965defd981bdbfd2511de7d9d4c542 Reviewed-on: https://go-review.googlesource.com/c/go/+/177637Reviewed-by: Benny Siegert <bsiegert@gmail.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Benny Siegert <bsiegert@gmail.com>
-
Joel Sing authored
Fix various bugs in the netbsd/arm64 runtime assembly. Updates #30824. Change-Id: I5ca10926ab663a8ff4df9973530e645e2469c1aa Reviewed-on: https://go-review.googlesource.com/c/go/+/177120Reviewed-by: Benny Siegert <bsiegert@gmail.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Benny Siegert <bsiegert@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ben Shi authored
A cross C compiler should be specified when cross building go for android on x86 host. This CL fixes the typo in README. Change-Id: Ideda915364d9f7f0fcd53146abc1e74506a8a8e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/177777Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Elias Naur <mail@eliasnaur.com>
-
Joey authored
Change-Id: I44af6cd8baa8fcd2a666429467fae4bed5f21fa0 GitHub-Last-Rev: d0c9722f082114b356de55fc79ce138ede019636 GitHub-Pull-Request: golang/go#32052 Reviewed-on: https://go-review.googlesource.com/c/go/+/177277Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
-
Keith Randall authored
Update #28603 Change-Id: I8bdbea57b3661e15dcc760d27252b794daa476db Reviewed-on: https://go-review.googlesource.com/c/go/+/177697Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
-
- 16 May, 2019 2 commits
-
-
Jay Conrod authored
If a user runs 'go get mod@vers' where the module transitively requires itself at a newer version, 'go get' attempts to perform a downgrade, which necessarily excludes the requested version of the module. Previously, we called mvs.BuildList with the requested module version as the target. This panicked because BuildList doesn't allow the target module (typically the main module) to require a newer version of itself. With this change, when we lose an upgrade due to a downgrade, we call mvs.BuildList through a wrapper that treats the lost module version as requirement of a synthetic root module, rather than the target module. This avoids the panic. This change also starts reporting errors when an upgraded module is lost entirely (downgrades caused the module to be completely removed from the build list). Fixes #31491 Change-Id: I70ca261c20af7553cad2d3b840a1eaf3d18a4191 Reviewed-on: https://go-review.googlesource.com/c/go/+/177602 Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Michael Anthony Knyszek authored
On most platforms newly-mapped memory is untouched, meaning the pages backing the region haven't been faulted in yet. However, we mark this memory as unscavenged which means the background scavenger aggressively "returns" this memory to the OS if the heap is small. The only platform where newly-mapped memory is actually unscavenged (and counts toward the application's RSS) is on Windows, since (*mheap).sysAlloc commits the reservation. Instead of making a special case for Windows, I change the requirements a bit for a sysReserve'd region. It must now be both sysMap'd and sysUsed'd, with sysMap being a no-op on Windows. Comments about memory allocation have been updated to include a more up-to-date mental model of which states a region of memory may be in (at a very low level) and how to transition between these states. Now this means we can correctly mark newly-mapped heap memory as scavenged on every platform, reducing the load on the background scavenger early on in the application for small heaps. As a result, heap-growth scavenging is no longer necessary, since any actual RSS growth will be accounted for on the allocation codepath. Finally, this change also cleans up grow a little bit to avoid pretending that it's freeing an in-use span and just does the necessary operations directly. Fixes #32012. Fixes #31966. Updates #26473. Change-Id: Ie06061eb638162e0560cdeb0b8993d94cfb4d290 Reviewed-on: https://go-review.googlesource.com/c/go/+/177097 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-