- 03 Jul, 2014 6 commits
-
-
Bill Thiede authored
LGTM=adg R=golang-codereviews, bradfitz, adg CC=golang-codereviews https://golang.org/cl/109970043
-
David Crawshaw authored
It snuck into cl/106380043. Too many active clients. LGTM=ruiu R=golang-codereviews, ruiu CC=golang-codereviews https://golang.org/cl/110830045
-
David Crawshaw authored
Based on cl/69170045 by Elias Naur. There are currently several schemes for acquiring a TLS slot to save the g register. None of them appear to work for android. The closest are linux and darwin. Linux uses a linker TLS relocation. This is not supported by the android linker. Darwin uses a fixed offset, and calls pthread_key_create until it gets the slot it wants. As the runtime loads late in the android process lifecycle, after an arbitrary number of other libraries, we cannot rely on any particular slot being available. So we call pthread_key_create, take the first slot we are given, and put it in runtime.tlsg, which we turn into a regular variable in cmd/ld. Makes android/arm cgo binaries work. LGTM=minux R=elias.naur, minux, dave, josharian CC=golang-codereviews https://golang.org/cl/106380043
-
Dmitriy Vyukov authored
The code in GC that handles gp->gobuf.ctxt is wrong, because it does not mark the ctxt object itself, if just queues the ctxt object for scanning. So the ctxt object can be collected as garbage. However, Gobuf.ctxt is void*, so it's always marked and scanned through G. LGTM=khr R=golang-codereviews, khr CC=golang-codereviews, khr, rsc https://golang.org/cl/105490044
-
Dmitriy Vyukov authored
Currently it says: --- PASS: TestDecrypt-2 (0.11s) pem_decrypt_test.go:17: test 0. %!s(x509.PEMCipher=1) --- PASS: TestEncrypt-2 (0.00s) pem_decrypt_test.go:42: test 0. %!s(x509.PEMCipher=1) LGTM=alex.brainman R=golang-codereviews, alex.brainman CC=golang-codereviews https://golang.org/cl/108400044
-
Aram Hăvărneanu authored
runtime·usleep and runtime·osyield fall back to calling an assembly wrapper for the libc functions in the absence of a m, so they can be called in cgo callback context. LGTM=rsc R=minux.ma, rsc CC=dave, golang-codereviews https://golang.org/cl/102620044
-
- 02 Jul, 2014 9 commits
-
-
Cristian Staretu authored
A temporary 512 bytes buffer is allocated for every call to readHeader. This buffer isn't returned to the caller and it could be reused to lower the number of memory allocations. This CL improves it by using a pool and zeroing out the buffer before putting it back into the pool. benchmark old ns/op new ns/op delta BenchmarkListFiles100k 545249903 538832687 -1.18% benchmark old allocs new allocs delta BenchmarkListFiles100k 2105167 2005692 -4.73% benchmark old bytes new bytes delta BenchmarkListFiles100k 105903472 54831527 -48.22% This improvement is very important if your code has to deal with a lot of tarballs which contain a lot of files. LGTM=dsymonds R=golang-codereviews, dave, dsymonds, bradfitz CC=golang-codereviews https://golang.org/cl/108240044
-
Cristian Staretu authored
A temporary 512 bytes buffer is allocated for every call to writeHeader. This buffer could be reused the lower the number of memory allocations. benchmark old ns/op new ns/op delta BenchmarkWriteFiles100k 634622051 583810847 -8.01% benchmark old allocs new allocs delta BenchmarkWriteFiles100k 2701920 2602621 -3.68% benchmark old bytes new bytes delta BenchmarkWriteFiles100k 115383884 64349922 -44.23% This change is very important if your code has to write a lot of tarballs with a lot of files. LGTM=dsymonds R=golang-codereviews, dave, dsymonds CC=golang-codereviews https://golang.org/cl/107440043
-
Adam Langley authored
Thanks to Cedric Staub for noting that a short session key would lead to an out-of-bounds access when conditionally copying the too short buffer over the random session key. LGTM=davidben, bradfitz R=davidben, bradfitz CC=golang-codereviews https://golang.org/cl/102670044
-
Russ Cox authored
The main changes fall into a few patterns: 1. Replace #define with enum. 2. Add /*c2go */ comment giving effect of #define. This is necessary for function-like #defines and non-enum-able #defined constants. (Not all compilers handle negative or large enums.) 3. Add extra braces in struct initializer. (c2go does not implement the full rules.) This is enough to let c2go typecheck the source tree. There may be more changes once it is doing other semantic analyses. LGTM=minux, iant R=minux, dave, iant CC=golang-codereviews https://golang.org/cl/106860045
-
Preetam Jinka authored
LGTM=josharian R=golang-codereviews, josharian CC=golang-codereviews https://golang.org/cl/110330043
-
Timo Truyts authored
LGTM=iant R=golang-codereviews, iant, bradfitz CC=golang-codereviews https://golang.org/cl/107390044
-
Brad Fitzpatrick authored
Generated by a+c. R=gobot CC=golang-codereviews https://golang.org/cl/111820043
-
Brad Fitzpatrick authored
Generated by a+c. R=gobot CC=golang-codereviews https://golang.org/cl/107450043
-
Aram Hăvărneanu authored
A TLS slot is reserved by _rt0_.*_plan9 as an automatic and its address (which is static on Plan 9) is saved in the global _privates symbol. The startup linkage now is exactly like that from Plan 9 libc, and the way we access g is exactly as if we'd have used privalloc(2). Aside from making the code more standard, this change drastically simplifies it, both for 386 and for amd64, and makes the Plan 9 code in liblink common for both 386 and amd64. The amd64 runtime code was cleared of nxm assumptions, and now runs on the standard Plan 9 kernel. Note handling fixes will follow in a separate CL. LGTM=rsc R=golang-codereviews, rsc, bradfitz, dave CC=0intro, ality, golang-codereviews, jas, minux.ma, mischief https://golang.org/cl/101510049
-
- 01 Jul, 2014 14 commits
-
-
Aram Hăvărneanu authored
We restored registers correctly in the usual case where the thread is a Go-managed thread and called runtime·sighandler, but we failed to do so when runtime·sigtramp was called on a cgo-created thread. In that case, runtime·sigtramp called runtime·badsignal, a Go function, and did not restore registers after it returned LGTM=rsc, dave R=rsc, dave CC=golang-codereviews, minux.ma https://golang.org/cl/105280050
-
Shenghou Ma authored
On amd64, the real time is reduced from 176.76s to 140.26s. On ARM, the real time is reduced from 921.61s to 726.30s. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/101580043
-
David Crawshaw authored
As android and linux have significant overlap, and because build tags are a poor way to represent an OS target, this CL introduces an exception into go/build: linux is treated as a synonym for android when matching files. http://golang.org/s/go14android https://groups.google.com/forum/#!topic/golang-dev/P1ATVp1mun0 LGTM=rsc, minux R=golang-codereviews, mikioh.mikioh, dave, aram, minux, gobot, rsc, aram.h, elias.naur, iant CC=golang-codereviews, rsc https://golang.org/cl/105270043
-
Russ Cox authored
Move decAlloc calls a bit higher in the call tree. Cleans code marginally, improves speed marginally. The benchmarks are noisy but the median time from 20 consective 1-second runs improves by about 2%. LGTM=r R=r CC=golang-codereviews https://golang.org/cl/105530043
-
Robert Griesemer authored
3-index slices of the form s[:len(s):len(s)] cannot be simplified to s[::len(s)]. LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/108330043
-
Robert Griesemer authored
TBR=rsc R=golang-codereviews CC=golang-codereviews https://golang.org/cl/111770043
-
Simon Whitehead authored
Fixes #7631. LGTM=gri R=golang-codereviews, bradfitz, gri CC=golang-codereviews https://golang.org/cl/101410046
-
Brad Fitzpatrick authored
Generated by a+c. R=gobot, rsc CC=golang-codereviews https://golang.org/cl/106340043
-
Brad Fitzpatrick authored
LGTM=rsc R=rsc, minux CC=golang-codereviews https://golang.org/cl/105480043
-
Rob Pike authored
CC=golang-codereviews https://golang.org/cl/101590043
-
Rob Pike authored
We are not the right people to support editor plugins, and the profusion of editors in this CL demonstrates the unreality of pretending to do so. People are free to create and advertise their own repos with support. For discussion: https://groups.google.com/forum/#!topic/golang-dev/SA7fD470FxU LGTM=rminnich, kamil.kisiel, gri, rsc, dave, josharian, ruiu R=golang-codereviews, rminnich, kamil.kisiel, gri, rsc, dominik.honnef, dave, josharian, ruiu, ajstarks CC=golang-codereviews https://golang.org/cl/105470043
-
Rémy Oudompheng authored
There is no reason to generate different code for cap and len. Fixes #8025. Fixes #8026. LGTM=rsc R=rsc, iant, khr CC=golang-codereviews https://golang.org/cl/93570044
-
Keith Randall authored
Breaks windows and race detector. TBR=rsc ««« original CL description runtime: stack allocator, separate from mallocgc In order to move malloc to Go, we need to have a separate stack allocator. If we run out of stack during malloc, malloc will not be available to allocate a new stack. Stacks are the last remaining FlagNoGC objects in the GC heap. Once they are out, we can get rid of the distinction between the allocated/blockboundary bits. (This will be in a separate change.) Fixes #7468 Fixes #7424 LGTM=rsc, dvyukov R=golang-codereviews, dvyukov, khr, dave, rsc CC=golang-codereviews https://golang.org/cl/104200047 »»» TBR=rsc CC=golang-codereviews https://golang.org/cl/101570044
-
Keith Randall authored
In order to move malloc to Go, we need to have a separate stack allocator. If we run out of stack during malloc, malloc will not be available to allocate a new stack. Stacks are the last remaining FlagNoGC objects in the GC heap. Once they are out, we can get rid of the distinction between the allocated/blockboundary bits. (This will be in a separate change.) Fixes #7468 Fixes #7424 LGTM=rsc, dvyukov R=golang-codereviews, dvyukov, khr, dave, rsc CC=golang-codereviews https://golang.org/cl/104200047
-
- 30 Jun, 2014 5 commits
-
-
David Crawshaw authored
LGTM=minux R=golang-codereviews, minux CC=golang-codereviews https://golang.org/cl/109220046
-
Rob Pike authored
The old code's structure needed to track indirections because of the use of unsafe. That is no longer necessary, so we can remove all that tracking. The code cleans up considerably but is a little slower. We may be able to recover that performance drop. I believe the code quality improvement is worthwhile regardless. BenchmarkEndToEndPipe 5610 5780 +3.03% BenchmarkEndToEndByteBuffer 3156 3222 +2.09% LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/103700043
-
Robert Griesemer authored
If the actual types of two reflect values are the same and the values are structs, they must have the same number of fields. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/108280043
-
Rob Pike authored
CC=golang-codereviews https://golang.org/cl/103690043
-
Rob Pike authored
This removes a major unsafe thorn in our side, a perennial obstacle to clean garbage collection. Not coincidentally: In cleaning this up, several bugs were found, including code that reached inside by-value interfaces to create pointers for pointer-receiver methods. Unsafe code is just as advertised. Performance of course suffers, but not too badly. The Pipe number is more indicative, since it's doing I/O that simulates a network connection. Plus these are end-to-end, so each end suffers only half of this pain. The edit is pretty much a line-by-line conversion, with a few simplifications and a couple of new tests. There may be more performance to gain. BenchmarkEndToEndByteBuffer 2493 3033 +21.66% BenchmarkEndToEndPipe 4953 5597 +13.00% Fixes #5159. LGTM=rsc R=rsc CC=golang-codereviews, khr https://golang.org/cl/102680045
-
- 29 Jun, 2014 2 commits
-
-
Dave Cheney authored
Fix copy paste error pointed out by rsc, https://golang.org/cl/107290043/diff/60001/test/fixedbugs/issue8074.go#newcode7 LGTM=ruiu, r R=golang-codereviews, ruiu, r CC=golang-codereviews https://golang.org/cl/106210047
-
Dmitriy Vyukov authored
Fixes #8299. R=golang-codereviews CC=golang-codereviews, khr, rsc https://golang.org/cl/103640044
-
- 28 Jun, 2014 4 commits
-
-
Evan Shaw authored
LGTM=r R=golang-codereviews, bradfitz, r CC=golang-codereviews https://golang.org/cl/109220044
-
Preetam Jinka authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/101510047
-
David Symonds authored
The only text that describes the accepted format is in the package doc, which is far away from these functions. The other flag types don't need this explicitness because they are more obvious. LGTM=r R=r CC=golang-codereviews https://golang.org/cl/101550043
-
Dmitriy Vyukov authored
R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/110080045
-