- 13 Jan, 2016 1 commit
-
-
Russ Cox authored
Fixes #13907. Change-Id: Ieaa5183f399b12a9177372212adf481c8f0b4a0d Reviewed-on: https://go-review.googlesource.com/18491Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Vlad Krasnov <vlad@cloudflare.com> Reviewed-by: Adam Langley <agl@golang.org>
-
- 12 Jan, 2016 6 commits
-
-
Ian Lance Taylor authored
Update #9401. Update #11925. Update #13919. Change-Id: I52c679353693e8165b2972d4d3974ee8bb1207ef Reviewed-on: https://go-review.googlesource.com/18542 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Denys Honsiorovskyi authored
Many browsers now support schemeless URLs in the Location headers and also it is allowed in the draft HTTP/1.1 specification (see http://stackoverflow.com/q/4831741#comment25926312_4831741), but Go standard library lacks support for them. This patch implements schemeless URLs support in http.Redirect(). Since url.Parse() correctly handles schemeless URLs, I've just added an extra condition to verify URL's Host part in the absoulute/relative check in the http.Redirect function. Also I've moved oldpath variable initialization inside the block of code where it is used. Change-Id: Ib8a6347816a83e16576f00c4aa13224a89d610b5 Reviewed-on: https://go-review.googlesource.com/14172Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
It would certainly be a mistake to invoke a write barrier while greying an object. Change-Id: I34445a15ab09655ea8a3628a507df56aea61e618 Reviewed-on: https://go-review.googlesource.com/18533 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Rick Hudson <rlh@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
It used to be the case that repeatedly getting one GC pointer and enqueuing one GC pointer could cause contention on the work buffers as each operation passed over the boundary of a work buffer. As of b6c0934a, we use a two buffer cache that prevents this sort of contention. Change-Id: I4f1111623f76df9c5493dd9124dec1e0bfaf53b7 Reviewed-on: https://go-review.googlesource.com/18532 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Austin Clements authored
This comment is probably a hold-over from when the heap bitmap was interleaved and the shift was 0, 2, 4, or 6. Now the shift is 0, 1, 2, or 3. Change-Id: I096ec729e1ca31b708455c98b573dd961d16aaee Reviewed-on: https://go-review.googlesource.com/18531 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Andrew Gerrand authored
Fixes #9228 Change-Id: Ic4df4a39f6f363bdd6eb9228c8164e6e9dccee1b Reviewed-on: https://go-review.googlesource.com/5561Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
- 11 Jan, 2016 8 commits
-
-
Michael Hudson-Doyle authored
Go fails to build on a system which has PIE enabled by default like this: /usr/bin/ld: -r and -pie may not be used together collect2: error: ld returned 1 exit status The only system I know that has this property right now is Ubuntu Xenial running on s390x, which is hardly the most accessible system, but it's planned to enable this on amd64 soon too. The fix is to pass -no-pie along with -Wl,-r to the compiler, but unfortunately that flag is very new as well. So this does a test compile of a trivial file to see if the flag is supported. Change-Id: I1345571142b7c3a96212e43297d19e84ec4a3d41 Reviewed-on: https://go-review.googlesource.com/18359Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
There are reports of corruption. Let's disable it for now (for Go 1.6, especially) until we can investigate and fix properly. Update #13892 Change-Id: I557275e5142fe616e8a4f89c00ffafb830eb3b78 Reviewed-on: https://go-review.googlesource.com/18540Reviewed-by: Dave Cheney <dave@cheney.net>
-
Ian Lance Taylor authored
Change-Id: I5a4a842cab2173357e8d3e349011c0c2b63be4f9 Reviewed-on: https://go-review.googlesource.com/18512Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
Change-Id: I5a0206e8074f3a2790954c45a217922b7b3fe851 Reviewed-on: https://go-review.googlesource.com/18487Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
Per suggestion from adonovan. Change-Id: Icbb4d2f201590bc94672b8d8141b6e7901e11dc5 Reviewed-on: https://go-review.googlesource.com/18510Reviewed-by: Robert Griesemer <gri@golang.org>
-
Robert Griesemer authored
In the presence of vendored packages, the path found in a package declaration may not be the path at which the package imported from srcDir was found. Use the correct package path. Change-Id: I74496c3cdf82a5dbd6a5bd189bb3cd0ca103fd52 Reviewed-on: https://go-review.googlesource.com/18460Reviewed-by: Alan Donovan <adonovan@google.com>
-
Ian Lance Taylor authored
Fixes #13881. Change-Id: Idff77db381640184ddd2b65022133bb226168800 Reviewed-on: https://go-review.googlesource.com/18449Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
-
Rick Hudson authored
Currently, due to an oversight, we only balance work buffers in background and idle workers and not in assists. As a result, in assist-heavy workloads, assists are likely to tie up large work buffers in per-P caches increasing the likelihood that the global list will be empty. This increases the likelihood that other GC workers will exit and assists will block, slowing down the system as a whole. Fix this by eagerly balancing work buffers as soon as the assists notice that the global buffers are empty. This makes it much more likely that work will be immediately available to other workers and assists. This change reduces the garbage benchmark time by 39% and fixes the regresssion seen at CL 15893 golang.org/cl/15893. Garbage benchmark times before and after this CL. Before GOPERF-METRIC:time=4427020 After GOPERF-METRIC:time=2721645 Fixes #13827 Change-Id: I9cb531fb873bab4b69ce9c1617e30df6c49cdcfe Reviewed-on: https://go-review.googlesource.com/18341Reviewed-by: Austin Clements <austin@google.com>
-
- 10 Jan, 2016 5 commits
-
-
Adam Langley authored
This change documents the behaviour change caused by https://go-review.googlesource.com/18480 in Go 1.6. Updates #13886 Change-Id: I2daa08a62775bbc209f0f4cbeae21b8184ce7609 Reviewed-on: https://go-review.googlesource.com/18481Reviewed-by: Russ Cox <rsc@golang.org>
-
Adam Langley authored
The AESNI GCM code decrypts and authenticates concurrently and so overwrites the destination buffer even in the case of an authentication failure. This change updates the documentation to make that clear and also mimics that behaviour in the generic code so that different platforms act identically. Fixes #13886 Change-Id: Idc54e51f01e27b0fc60c1745d50bb4c099d37e94 Reviewed-on: https://go-review.googlesource.com/18480Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Yao Zhang authored
mips64 builder and one machine of the mips64le builder has small amount of memory. Since CL 18199, they have been running slowly, as more processes were launched in running 'test' directory, and a lot of swap were used. This CL brings all.bash from 5h back to 3h on Loongson 2E with 512 MB memory. Change-Id: I4a22e239a542a99ba5986753205d8cd1f4b3d3c6 Reviewed-on: https://go-review.googlesource.com/18483Reviewed-by: Minux Ma <minux@golang.org> Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Updates http2 to x/net git rev 0e6d34ef942 for https://golang.org/cl/18472 which means we'll get to delete a ton of grpc-go code and just use the standard library's HTTP client instead. Also, the comments in this CL aren't entirely accurate it turns out. RFC 2616 says: "The Trailer header field can be used to indicate which header fields are included in a trailer (see section 14.40)." And 14.40: " An HTTP/1.1 message SHOULD include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient to know which header fields to expect in the trailer. If no Trailer header field is present, the trailer SHOULD NOT include any header fields. See section 3.6.1 for restrictions on the use of trailer fields in a "chunked" transfer-coding." So it's really a SHOULD more than a MUST. And gRPC (at least Google's server) doesn't predeclare "grpc-status" ahead of time in a Trailer Header, so we'll be lenient. We were too strict anyway. It's also not a concern for the Go client we have a different place to populate the Trailers, and it won't confuse clients which aren't looking for them. The ResponseWriter server side is more complicated (and strict), though, since we don't want to widen the ResponseWriter interface. So the Go server still requires that you predeclare Trailers. Change-Id: Ia2defc11a2469fb8570ecfabb8453537121084eb Reviewed-on: https://go-review.googlesource.com/18473 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Harshavardhana authored
Fixes #13893 Change-Id: I2577b38fdb19299227dc146f707cf9df663dcdfc Reviewed-on: https://go-review.googlesource.com/18471 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 09 Jan, 2016 5 commits
-
-
Emmanuel Odeke authored
Change-Id: I08d77d52b68b062c2eb1901fcfca34d45a210cce Reviewed-on: https://go-review.googlesource.com/18142Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matt Robenolt authored
Change-Id: Ia6d40ead1e54dd0b8998370cbabc2d7cd8b7aa0b Reviewed-on: https://go-review.googlesource.com/18470Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Mikio Hara authored
Change-Id: I95c6c85eecb53ffe52b64d521180148b624e9424 Reviewed-on: https://go-review.googlesource.com/18423Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
The previous behaviour of installing the signal handlers in a separate thread meant that Go initialization raced with non-Go initialization if the non-Go initialization also wanted to install signal handlers. Make installing signal handlers synchronous so that the process-wide behavior is predictable. Update #9896. Change-Id: Ice24299877ec46f8518b072a381932d273096a32 Reviewed-on: https://go-review.googlesource.com/18150 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Robert Griesemer authored
TBR adonovan Fixes #13882. Change-Id: I8664669f5d6adfec6f16e154263b1f0ea8988175 Reviewed-on: https://go-review.googlesource.com/18445Reviewed-by: Robert Griesemer <gri@golang.org>
-
- 08 Jan, 2016 15 commits
-
-
Austin Clements authored
Go 1.6 simplified the GC phases. The "synchronize Ps" phase no longer exists and "root scan" and "mark" phases have been combined. Update the gctrace line implementation and documentation to remove the unused phases. Fixes #13536. Change-Id: I4fc37a3ce1ae3a99d48c0be2df64cbda3e05dee6 Reviewed-on: https://go-review.googlesource.com/18458 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Russ Cox <rsc@golang.org>
-
Robert Griesemer authored
Fixes #13688. Change-Id: I53363aeeeba4560211d56d4571a8e058d5dbbd8a Reviewed-on: https://go-review.googlesource.com/18308Reviewed-by: Alan Donovan <adonovan@google.com>
-
Austin Clements authored
Sigh. Sleeps on FreeBSD also yield the rest of the time slice and profiling signals are only delivered when a process completes a time slice (worse, itimer time is only accounted to the process that completes a time slice). It's less noticeable than the other BSDs because the default tick rate is 1000Hz, but it's still failing regularly. Fixes #13846. Change-Id: I41bf116bffe46682433b677183f86944d0944ed4 Reviewed-on: https://go-review.googlesource.com/18455Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Austin Clements <austin@google.com>
-
Brad Fitzpatrick authored
Change-Id: Ib838d2b98e3f84ffd240849817cafc69415ba74e Reviewed-on: https://go-review.googlesource.com/18376Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
Fixes #13875. Change-Id: Icbb85c858d0bc545499a2b31622e9e7abdd7e5f9 Reviewed-on: https://go-review.googlesource.com/18441Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Fixes build. Change-Id: I5235deed7b93157854acb79c15e2e99cc28d300a Reviewed-on: https://go-review.googlesource.com/18456Reviewed-by: Russ Cox <rsc@golang.org>
-
Mikio Hara authored
Change-Id: I728d4c709c4122fe4b96e1350be73696ac6fb1f7 Reviewed-on: https://go-review.googlesource.com/18422Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
There are fewer special cases this way: the import map applies to all import paths, not just the ones not spelled "unsafe". This is also consistent with what the code in cmd/go and go/build expects. They make no exception for "unsafe". For #13703. Change-Id: I622295261ca35a6c1e83e8508d363bddbddb6c0a Reviewed-on: https://go-review.googlesource.com/18438Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Brad Fitzpatrick authored
Third time's a charm. Thanks to Ralph Corderoy for noticing the DEL omission. Update #11207 Change-Id: I174fd01eaecceae1eb220f2c9136e12d40fbe943 Reviewed-on: https://go-review.googlesource.com/18375Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
Looking for vendor directories is a better default. Fixes #13772 Change-Id: Iabbaea71ccc67b72f14f1f412dc8ab70cb41996d Reviewed-on: https://go-review.googlesource.com/18450Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Ian Lance Taylor authored
We're only getting away with it today by luck. Change-Id: I24d1cceee4d20c5181ca64fceda152e875f6ad81 Reviewed-on: https://go-review.googlesource.com/18440 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Ian Lance Taylor authored
Also nosplit where needed. Change-Id: I1e3f6f8f76df9ee7e87ed1b8560cef145928314c Reviewed-on: https://go-review.googlesource.com/18395Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
This reverts commit bb8c2e19. Change-Id: I9bc089e9f2296805ef055b98e8c86ba73af30226 Reviewed-on: https://go-review.googlesource.com/18439Reviewed-by: Russ Cox <rsc@golang.org>
-
Joel Sing authored
The cgoTestSO test currently fails when run on FreeBSD amd64 with GOHOSTARCH=386. This is due to it failing to find the shared object. On FreeBSD 64-bit architectures, the linker for 32-bit objects looks for a separate environment variable. Export both LD_LIBRARY_PATH and LD_32_LIBRARY_PATH on FreeBSD when GOHOSTARCH=386. Update issue #13873. Change-Id: I1fb20dd04eb2007061768b2e4530886521813d42 Reviewed-on: https://go-review.googlesource.com/18420Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
Reading 32,767 is too many on some versions of Windows. The exact upper bound is unclear. For #13697, but may not fix the problem on all systems. Change-Id: I197021ed60cbcd33c91ca6ceed456ec3d5a6c9d6 Reviewed-on: https://go-review.googlesource.com/18433Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-