- 13 Nov, 2015 13 commits
-
-
Joe Tsai authored
The gzip package is asymmetrical in the way it handles headers. In Writer, the Header is written on the first call to Write, Flush, or Close. In Reader, the Header is read on calls to NewReader or Reset as opposed to after the first Read. Thus, we document this difference. Fixes #13211 Change-Id: I5f87beff036e5e2fd68a02a15fdb7137e9ca4c37 Reviewed-on: https://go-review.googlesource.com/16838Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Shenghou Ma authored
Fixes #12540. Change-Id: I7893fdc023145b0aca4b4c7df7e08e47edcf5bba Reviewed-on: https://go-review.googlesource.com/16902 Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Matthew Dempsky authored
Allows removing fields that aren't relevant to a particular OS or changing their types to match the underlying OS system calls they'll be used for. Change-Id: I5cea89ee77b4e7b985bff41337e561887c3272ff Reviewed-on: https://go-review.googlesource.com/16176Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com>
-
Shenghou Ma authored
so that GO_TEST_TIMEOUT_SCALE can be applied too. It's for the mips64 builder, which is so slow that the go1 benchmark can't finish startup within 10 minutes. Change-Id: I1b824eb0649460101b294fb442da784e872403e7 Reviewed-on: https://go-review.googlesource.com/16901Reviewed-by:
-
Matt Layher authored
Replaces PID in PaxHeaders with 0. Sorts PAX header keys before writing them to the archive. Fixes #12358 Change-Id: If239f89c85f1c9d9895a253fb06a47ad44960124 Reviewed-on: https://go-review.googlesource.com/13975Reviewed-by:
Joe Tsai <joetsai@digital-static.net>
-
Matthew Dempsky authored
We're allocating TLS storage for m0 anyway, so might as well use it. Change-Id: I7dc20bbea5320c8ab8a367f18a9540706751e771 Reviewed-on: https://go-review.googlesource.com/16890 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by:
-
Yasuhiro Matsumoto authored
Fixes #13198 The output of netsh is encoded with ANSI encoding. So doesn't match with UTF-8 strings. Write output as UTF-8 using powershell. Change-Id: I6c7e93c590ed407f24ae847601d71df9523e028c Reviewed-on: https://go-review.googlesource.com/16756 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Alex Brainman <alex.brainman@gmail.com>
-
Shenghou Ma authored
It doesn't seem to help on modern processors and it makes Go impossible to run on Pentium MMX (which is the documented minimum hardware requirement.) Old is with prefetch, new is w/o. Both are compiled with GO386=sse2. Benchmarking is done on Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz. name old time/op new time/op delta BinaryTree17-4 2.89s ± 2% 2.87s ± 0% ~ (p=0.061 n=11+10) Fannkuch11-4 3.65s ± 0% 3.65s ± 0% ~ (p=0.365 n=11+11) FmtFprintfEmpty-4 52.1ns ± 0% 52.1ns ± 0% ~ (p=0.065 n=10+9) FmtFprintfString-4 168ns ± 0% 167ns ± 0% -0.48% (p=0.000 n=8+10) FmtFprintfInt-4 167ns ± 0% 167ns ± 1% ~ (p=0.591 n=9+10) FmtFprintfIntInt-4 295ns ± 0% 292ns ± 0% -0.99% (p=0.000 n=9+10) FmtFprintfPrefixedInt-4 327ns ± 0% 326ns ± 0% -0.24% (p=0.007 n=10+10) FmtFprintfFloat-4 431ns ± 0% 431ns ± 0% -0.07% (p=0.000 n=10+11) FmtManyArgs-4 1.13µs ± 0% 1.13µs ± 0% -0.37% (p=0.009 n=11+11) GobDecode-4 9.36ms ± 1% 9.33ms ± 0% -0.31% (p=0.006 n=11+10) GobEncode-4 7.38ms ± 1% 7.38ms ± 1% ~ (p=0.797 n=11+11) Gzip-4 394ms ± 0% 395ms ± 1% ~ (p=0.519 n=11+11) Gunzip-4 65.4ms ± 0% 65.4ms ± 0% ~ (p=0.739 n=10+10) HTTPClientServer-4 52.4µs ± 1% 52.5µs ± 1% ~ (p=0.748 n=11+11) JSONEncode-4 19.0ms ± 0% 19.0ms ± 0% ~ (p=0.780 n=9+10) JSONDecode-4 59.6ms ± 0% 59.6ms ± 0% ~ (p=0.720 n=9+10) Mandelbrot200-4 4.09ms ± 0% 4.09ms ± 0% ~ (p=0.295 n=11+9) GoParse-4 3.45ms ± 1% 3.43ms ± 1% -0.35% (p=0.040 n=11+11) RegexpMatchEasy0_32-4 101ns ± 1% 101ns ± 1% ~ (p=1.000 n=11+11) RegexpMatchEasy0_1K-4 796ns ± 0% 796ns ± 0% ~ (p=0.954 n=10+8) RegexpMatchEasy1_32-4 110ns ± 0% 110ns ± 1% ~ (p=0.289 n=9+11) RegexpMatchEasy1_1K-4 991ns ± 0% 991ns ± 0% ~ (p=0.784 n=10+8) RegexpMatchMedium_32-4 131ns ± 0% 130ns ± 0% -0.42% (p=0.004 n=11+9) RegexpMatchMedium_1K-4 41.9µs ± 1% 41.6µs ± 0% ~ (p=0.067 n=11+9) RegexpMatchHard_32-4 2.34µs ± 0% 2.34µs ± 0% ~ (p=0.208 n=11+11) RegexpMatchHard_1K-4 70.9µs ± 0% 71.0µs ± 0% ~ (p=0.968 n=9+10) Revcomp-4 819ms ± 0% 818ms ± 0% ~ (p=0.251 n=10+11) Template-4 73.9ms ± 0% 73.8ms ± 0% -0.25% (p=0.013 n=10+11) TimeParse-4 414ns ± 0% 414ns ± 0% ~ (p=0.809 n=11+10) TimeFormat-4 485ns ± 0% 485ns ± 0% ~ (p=0.404 n=11+7) name old speed new speed delta GobDecode-4 82.0MB/s ± 1% 82.3MB/s ± 0% +0.31% (p=0.007 n=11+10) GobEncode-4 104MB/s ± 1% 104MB/s ± 1% ~ (p=0.797 n=11+11) Gzip-4 49.2MB/s ± 0% 49.1MB/s ± 1% ~ (p=0.507 n=11+11) Gunzip-4 297MB/s ± 0% 297MB/s ± 0% ~ (p=0.670 n=10+10) JSONEncode-4 102MB/s ± 0% 102MB/s ± 0% ~ (p=0.794 n=9+10) JSONDecode-4 32.6MB/s ± 0% 32.6MB/s ± 0% ~ (p=0.334 n=9+9) GoParse-4 16.8MB/s ± 1% 16.9MB/s ± 1% ~ (p=0.052 n=11+11) RegexpMatchEasy0_32-4 314MB/s ± 0% 314MB/s ± 1% ~ (p=0.618 n=11+11) RegexpMatchEasy0_1K-4 1.29GB/s ± 0% 1.29GB/s ± 0% ~ (p=0.315 n=10+10) RegexpMatchEasy1_32-4 290MB/s ± 1% 290MB/s ± 1% ~ (p=0.667 n=10+11) RegexpMatchEasy1_1K-4 1.03GB/s ± 0% 1.03GB/s ± 0% ~ (p=0.829 n=10+8) RegexpMatchMedium_32-4 7.63MB/s ± 0% 7.65MB/s ± 0% ~ (p=0.142 n=11+11) RegexpMatchMedium_1K-4 24.4MB/s ± 1% 24.6MB/s ± 0% ~ (p=0.063 n=11+9) RegexpMatchHard_32-4 13.7MB/s ± 0% 13.7MB/s ± 0% ~ (p=0.302 n=11+11) RegexpMatchHard_1K-4 14.4MB/s ± 0% 14.4MB/s ± 0% ~ (p=0.784 n=9+10) Revcomp-4 310MB/s ± 0% 311MB/s ± 0% ~ (p=0.243 n=10+11) Template-4 26.2MB/s ± 0% 26.3MB/s ± 0% +0.24% (p=0.009 n=10+11) Update #12970. Change-Id: Id185080687a60c229a5cb2e5220e7ca1b53910e2 Reviewed-on: https://go-review.googlesource.com/15999Reviewed-by:
Austin Clements <austin@google.com> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Shenghou Ma authored
Fixes #12391. Change-Id: I31211cd711c035151785c3083571594d15c7d93e Reviewed-on: https://go-review.googlesource.com/16873Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: I4d079d29408e5344701056c88882cfd3b3857478 Reviewed-on: https://go-review.googlesource.com/15973Reviewed-by:
-
Michael Hudson-Doyle authored
Change-Id: I3980d82c7df95e69522c3d2c90311f89c6fef0e1 Reviewed-on: https://go-review.googlesource.com/15972Reviewed-by:
-
Michael Hudson-Doyle authored
Change-Id: Ie79f72786b1d7154f1910e717a0faf354b913b89 Reviewed-on: https://go-review.googlesource.com/15970Reviewed-by:
-
Michael Hudson-Doyle authored
Change-Id: I79c60241df6c785f35371e70c777a7bd6e93571c Reviewed-on: https://go-review.googlesource.com/15968Reviewed-by:
-
- 12 Nov, 2015 27 commits
-
-
Michael Hudson-Doyle authored
Change-Id: Ifba76413b8aa78a221385bf505b92a3a5fbc3d24 Reviewed-on: https://go-review.googlesource.com/16713Reviewed-by:
-
Michael Hudson-Doyle authored
This requires changing the tls access code to match the patterns documented in the ABI documentation or the system linker will "optimize" it into ridiculousness. With this change, -buildmode=pie works, although as it is tested in testshared, the tests are not run yet. Change-Id: I1efa6687af0a5b8db3385b10f6542a49056b2eb3 Reviewed-on: https://go-review.googlesource.com/15971Reviewed-by:
-
Michael Hudson-Doyle authored
Change-Id: I0a8448c2b69f5cfa6f099d772f5eb3412f853045 Reviewed-on: https://go-review.googlesource.com/15969Reviewed-by:
-
Michael Hudson-Doyle authored
The PowerPC ISA does not have a PC-relative load instruction, which poses obvious challenges when generating position-independent code. The way the ELFv2 ABI addresses this is to specify that r2 points to a per "module" (shared library or executable) TOC pointer. Maintaining this pointer requires cooperation between codegen and the system linker: * Non-leaf functions leave space on the stack at r1+24 to save the TOC pointer. * A call to a function that *might* have to go via a PLT stub must be followed by a nop instruction that the system linker can replace with "ld r1, 24(r1)" to restore the TOC pointer (only when dynamically linking Go code). * When calling a function via a function pointer, the address of the function must be in r12, and the first couple of instructions (the "global entry point") of the called function use this to derive the address of the TOC for the module it is in. * When calling a function that is implemented in the same module, the system linker adjusts the call to skip over the instructions mentioned above (the "local entry point"), assuming that r2 is already correctly set. So this changeset adds the global entry point instructions, sets the metadata so the system linker knows where the local entry point is, inserts code to save the TOC pointer at 24(r1), adds a nop after any call not known to be local and copes with the odd non-local code transfer in the runtime (e.g. the stuff around jmpdefer). It does not actually compile PIC yet. Change-Id: I7522e22bdfd2f891745a900c60254fe9e372c854 Reviewed-on: https://go-review.googlesource.com/15967Reviewed-by:
-
Matthew Dempsky authored
darwin/386, freebsd/386, and linux/386 use a setldt system call to setup each M's thread-local storage area, and they need access to the M's id for this. The current code copies m.id into m.tls[0] (and this logic has been cargo culted to OSes like NetBSD and OpenBSD, which don't even need m.id to configure TLS), and then the 386 assembly loads m.tls[0]... but since the assembly code already has a pointer to the M, it might as well just load m.id directly. Change-Id: I1a7278f1ec8ebda8d1de3aa3a61993070e3a8cdf Reviewed-on: https://go-review.googlesource.com/16881 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Michael Hudson-Doyle authored
The larger stack frames causes the nosplit stack to overflow so the next change increases the stackguard. Change-Id: Ib2b4f24f0649eb1d13e3a58d265f13d1b6cc9bf9 Reviewed-on: https://go-review.googlesource.com/15964Reviewed-by:
-
Michael Hudson-Doyle authored
Larger stack frames mean nosplit functions use more stack and so the limit needs to increase. The change to test/nosplit.go is a bit ugly but I can't really think of a way to make it nicer. Change-Id: I2616b58015f0b62abbd62951575fcd0d2d8643c2 Reviewed-on: https://go-review.googlesource.com/16504Reviewed-by:
-
Matthew Dempsky authored
Apparently its last use was removed in CL 8899. Change-Id: I4f3a789b3cc4c249582e81463af62b576a281e40 Reviewed-on: https://go-review.googlesource.com/16880 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Minux Ma <minux@golang.org> Reviewed-by:
-
Dmitry Vyukov authored
The new revision is 389d49d4943780efbfcd2a434f4462b6d0f23c44 (Nov 13, 2015). The runtimes are built using the new x/build/cmd/racebuild utility. This update fixes a bug in race detection algorithm that can lead to occasional false negatives (#10589). But generally just brings in an up-to-date runtime. Update #8653 Fixes #10589 Change-Id: I7ac9614d014ee89c2302ce5e096d326ef293f367 Reviewed-on: https://go-review.googlesource.com/16827Reviewed-by:
Keith Randall <khr@golang.org>
-
Shenghou Ma authored
Change-Id: I37bac9680efdfd797ca5dca90bd9a9e1001bfb68 Reviewed-on: https://go-review.googlesource.com/16874Reviewed-by:
Michael Matloob <matloob@golang.org>
-
Michael Matloob authored
As per mdempsky's comment on golang.org/cl/14204, textflag.h is copied to the includes dir by cmd/dist, and the copy in runtime/internal/atomic is not actually being used. Updates #11647 Change-Id: Ie95c08903a9df54cea4c70ee9d5291176f7b5609 Reviewed-on: https://go-review.googlesource.com/16871 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Michael Hudson-Doyle authored
A forward port of https://codereview.appspot.com/124900043/ which somehow got lost somewhere. Fixes #13024 Change-Id: Iab128899e65c51d90f6704e3e1b2fc9326e3a1c2 Reviewed-on: https://go-review.googlesource.com/16853Reviewed-by:
-
Daniel Theophanes authored
Fixes #7864 Change-Id: Id13369352aeccac8387876f0b911e383c543c28e Reviewed-on: https://go-review.googlesource.com/16714Reviewed-by:
-
Yasuhiro Matsumoto authored
Fixes #10802 Compare Volume name and each path elements using strings.EqualFold. Change-Id: Ibdefdb801d0326e53755bc9cc8c10eed998094e5 Reviewed-on: https://go-review.googlesource.com/16795Reviewed-by:
-
Shenghou Ma authored
Change-Id: I22216df83898e560cfe6d97344f05e3678c2db99 Reviewed-on: https://go-review.googlesource.com/16872Reviewed-by:
-
Michael Matloob authored
Somehow these were left out of the orignial CL. Updates #11647 Change-Id: I058a30eaa25fbb72d60e7fb6bc9ff0a3b54fdb2a Reviewed-on: https://go-review.googlesource.com/16870Reviewed-by:
-
Alberto Bertogli authored
Calling flag.Parse twice can be problematic if other goroutines called flag.Parsed in between: the race detector complains due to the write after read from a different goroutine. This can happen if TestMain calls flag.Parse and launches goroutines that call flag.Parsed, for example if it initializes a server which checks flags. This patch makes testing.M.Run only parse the flags if they have not been parsed already. Change-Id: Id9f8c31c5f90614e3f34c63d1a32cf7e9055d68e Reviewed-on: https://go-review.googlesource.com/16739Reviewed-by:
-
Austin Clements authored
The heap profile is only guaranteed to be up-to-date after two GC cycles, so force two GCs instead of just one. Updates #13098. Change-Id: I4fb9287b698f4a3b90b8af9fc6a2efb3b082bfe5 Reviewed-on: https://go-review.googlesource.com/16848Reviewed-by:
-
Michael Matloob authored
I made a copy of the per-arch _CacheLineSize definitons when checking in runtime/internal/atomic. Now that runtime/internal/sys is checked in, we can use the definition there. Change-Id: I7242f6b633e4164f033b67ff471416b9d71c64d2 Reviewed-on: https://go-review.googlesource.com/16847Reviewed-by:
-
Austin Clements authored
sigprof tracebacks the stack across systemstack switches to make profile tracebacks more complete. However, it does this even if the user stack is currently being copied, which means it may be in an inconsistent state that will cause the traceback to panic. One specific way this can happen is during stack shrinking. Some goroutine blocks for STW, then enters gchelper, which then assists with root marking. If that root marking happens to pick the original goroutine and its stack needs to be shrunk, it will begin to copy that stack. During this copy, the stack is generally inconsistent and, in particular, the actual locations of the stack barriers and their recorded locations are temporarily out of sync. If a SIGPROF happens during this inconsistency, it will walk the stack all the way back to the blocked goroutine and panic when it fails to unwind the stack barriers. Fix this by disallowing jumping to the user stack during SIGPROF if that user stack is in the process of being copied. Fixes #12932. Change-Id: I9ef694c2c01e3653e292ce22612418dd3daff1b4 Reviewed-on: https://go-review.googlesource.com/16819Reviewed-by:
Daniel Morsing <daniel.morsing@gmail.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Burcu Dogan authored
This reverts commit bc1f9d20. The current go-get strategy doesn't support cases that servers cannot handle shallow clients. Also, `go get -u` is broken and is not compatible with already go-getted unshallow repos. Fixes #13213. Fixes #13206. Change-Id: Ie89d7603d96d323db64ad82997793fda0972f709 Reviewed-on: https://go-review.googlesource.com/16832Reviewed-by:
-
Michael Matloob authored
The file was automatically placed in the cl by a tool I had built. Since the compiler doesn't hook into the atomic package, it's unnecessary. Change-Id: I631fd876813b381bb12604865b00fc5b268dce84 Reviewed-on: https://go-review.googlesource.com/16844Reviewed-by:
-
Brad Fitzpatrick authored
I keep losing this utility, used as part of other tools to auto-update the AUTHORS and CONTRIBUTORS files. Check it in to the repo so I don't lose it, and so others can use it as well. Updates #12042 Change-Id: Ib5886b85799087aaaddcec4c81169e2726322c05 Reviewed-on: https://go-review.googlesource.com/16824Reviewed-by:
-
Russ Cox authored
Fixes #13214. Change-Id: Id8fbb252b8beadb0b41f839dcd85d6165dea86a3 Reviewed-on: https://go-review.googlesource.com/16845Reviewed-by:
-
Michael Matloob authored
runtime/internal/sys will hold system-, architecture- and config- specific constants. Updates #11647 Change-Id: I6db29c312556087a42e8d2bdd9af40d157c56b54 Reviewed-on: https://go-review.googlesource.com/16817Reviewed-by:
-
Austin Clements authored
The heapsampling.go test occasionally fails on some architectures because it finds zero heap samples in main.alloc. This happens because the byte and object counts are only updated at a GC. Hence, if a GC happens part way through allocInterleaved, but then doesn't happen after we start calling main.alloc, checkAllocations will see buckets for the lines in main.alloc (which are created eagerly), but the object and byte counts will be zero. Fix this by forcing a GC to update the profile before we collect it. Fixes #13098. Change-Id: Ia7a9918eea6399307f10499dd7abefd4f6d13cf6 Reviewed-on: https://go-review.googlesource.com/16846 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
Correct an error in the last change: it caused runtime/cgo and runtime/race to not depend on runtime. Fixes #13214. Change-Id: Ib48b3b5e9a74567ddfaccb7ab4a897ee2aedc2b8 Reviewed-on: https://go-review.googlesource.com/16837Reviewed-by:
-
