- 06 Oct, 2015 10 commits
-
-
Michael Hudson-Doyle authored
It is generally expected that the ELF flags of a dynamically linked executable and the libraries it links against match. Go's linker currently always produces executables with flags that do not declare a float abi (hard, soft) at all, but when cgo is involved it is unlikely that this matches the system libraries being linked against -- really the decision about ABI is made by the C compiler during the invocation of cgo. This change is basically a port of the code from binutils that parses the ".ARM.attributes" section to check for the tag that declares that the code is built for the hard-float ABI. Fixes #7094 Change-Id: I737c8f3b5ed4af545cfc3e86722d03eb83083402 Reviewed-on: https://go-review.googlesource.com/14860 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Minux Ma <minux@golang.org>
-
Shenghou Ma authored
Fixes #12844. Change-Id: Id51b24aae239fd2e1fb1cd0bc9fe443186301044 Reviewed-on: https://go-review.googlesource.com/15440Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Shenghou Ma authored
Change-Id: Id6cb5e3d40e8a2ded6359aa7fcdc012861cc3994 Reviewed-on: https://go-review.googlesource.com/14545Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Shenghou Ma authored
Change-Id: I772d1bc3e394cdd707f210f2aaff77100d299e24 Reviewed-on: https://go-review.googlesource.com/15380Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Joe Tsai authored
Motivation: * There are an increasing number of "one-off" corrupt files added to make sure that package does not succeed or crash on them. Instead, allow for the test to specify the error that is expected to occur (if any). * Also, fold in the logic to check the MD5 checksum into this function. The following tests are being removed: * TestIncrementalRead: Done by TestReader by using io.CopyBuffer with a buffer of 8. This achieves the same behavior as this test. * TestSparseEndToEnd: Since TestReader checks the MD5 checksums if the input corpus provides them, then this is redundant. * TestSparseIncrementalRead: Redundant for the same reasons that TestIncrementalRead is now redundant * TestNegativeHdrSize: Added to TestReader corpus * TestIssue10968: Added to TestReader corpus * TestIssue11169: Added to TestReader corpus With this change, code coverage did not change: 85.3% Change-Id: I8550d48657d4dbb8f47dfc3dc280758ef73b47ec Reviewed-on: https://go-review.googlesource.com/15176Reviewed-by:
-
Michael Hudson-Doyle authored
This lets us re-enable duffzero. Fixes #12108 Change-Id: Iefd24d26eaa56067caa2c29ff99cd20a42d8714a Reviewed-on: https://go-review.googlesource.com/14937Reviewed-by:
Keith Randall <khr@golang.org>
-
Katrina Owen authored
Change-Id: I6d9a8886cccf1c396ea2dbc659c5bf7548179751 Reviewed-on: https://go-review.googlesource.com/15435Reviewed-by:
-
Joe Tsai authored
Let C be whether c valid Let E be whether err is non-nil The old comment explicitly says that (~C → E). However, that does call into question whether (E → ~C), which causes doubts for users. Without a comment at all, it is obvious that only (E
↔ ~C) makes sense. Fixes #11308 Change-Id: I5a7d51ceb509057eccca91f57a7e48c9d1c6d112 Reviewed-on: https://go-review.googlesource.com/15256Reviewed-by: -
Joe Tsai authored
The later part of the docstring simply talks about "offset" but does not disambiguate what it is relative to. For both the return value and valid offsets to seek to, it only makes sense in the context of "offset relative to origin of file". Fixes #11877 Change-Id: Ic238a407cf8e8fdd64991d98a6584cdc8a51cd6b Reviewed-on: https://go-review.googlesource.com/15257Reviewed-by:
-
Nodir Turakulov authored
Usage of all commands is printed to stderr, except go test, which is printed to stdout. This is inconsistent. Print `go test -help` to stderr instead. R=rsc@golang.org Change-Id: I079f4788134bf9aedcccc26838879eedad1c925e Reviewed-on: https://go-review.googlesource.com/15434Reviewed-by:
-
- 05 Oct, 2015 6 commits
-
-
Ian Lance Taylor authored
The net package already has support for limited uses of the strconv package. Despite this, a few uses of strconv have crept in over time. Remove them and use the existing net support instead. Change-Id: Icdb4bdaa8e1197f1119a96cddcf548ed4a551b74 Reviewed-on: https://go-review.googlesource.com/15400 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
Didier Spezia authored
cgo panics in Package.rewriteRef for: var a = C.enum_test(1) or p := new(C.enum_test) when the corresponding enum type is not defined. Check nil values for Type fields and issue a proper error instead. Fixes #11097 Updates #12160 Change-Id: I5821d29097ef0a36076ec5273125b09846c7d832 Reviewed-on: https://go-review.googlesource.com/15264Reviewed-by:
-
Kenny Grant authored
The existing serve() method returns a zero-length response body when it encounters an error, which results in a blank page and no visible error in browsers. This change sends a response body explaining the error for display in browsers. Fixes #12745 Change-Id: I9dc3b95ad88cb92c18ced51f6b52bd3b2c1b974c Reviewed-on: https://go-review.googlesource.com/15018 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ilya Tocar authored
Support VZEROUPPER, VMOVNTDQ, VMOVDQU, VMOVDQA. Use MOVHD* for names, where HD stands for HexaDeca (16). Change-Id: I9b1ea52e7ef0714a3d2aeb31ec1823fe509a047e Reviewed-on: https://go-review.googlesource.com/14127 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Raul Silvera authored
The current heap sampling introduces some bias that interferes with unsampling, producing unexpected heap profiles. The solution is to use a Poisson process to generate the sampling points, using the formulas described at https://en.wikipedia.org/wiki/Poisson_process This fixes #12620 Change-Id: If2400809ed3c41de504dd6cff06be14e476ff96c Reviewed-on: https://go-review.googlesource.com/14590Reviewed-by:
-
Michael Hudson-Doyle authored
ppc64 codegen assumes that it is OK to stomp on r31 at any time, but it is not excluded from the set of registers that regopt is allowed to use. Fixes #12597 Change-Id: I29c7655e32abd22f3c21d88427b73e4fca055233 Reviewed-on: https://go-review.googlesource.com/15245Reviewed-by:
-
- 04 Oct, 2015 3 commits
-
-
David Chase authored
Turns out the summary information for the ... args was already correctly computed, all that lacked was to make use of it and correct tests that documented our prior deficiencies. Fixes #12006 Change-Id: Ie8adfab7547f179391d470679598f0904aabf9f7 Reviewed-on: https://go-review.googlesource.com/15200Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Shenghou Ma authored
The runtime/zgoos_$GOOS.go and runtime/zgoarch_$GOARCH.go files are in the repository now, so the message is actually incorrect (running make.bash won't generate those). The reason is probably wrong $GOROOT. Change-Id: I8dc125594c52d666eca91fd5af48b60d12d599b8 Reviewed-on: https://go-review.googlesource.com/15221Reviewed-by:
-
Shenghou Ma authored
Fixes #12601. Change-Id: I0be69ffe9ba19934aaef1651845c725708db77de Reviewed-on: https://go-review.googlesource.com/14546Reviewed-by:
-
- 03 Oct, 2015 6 commits
-
-
Didier Spezia authored
CGOPKGPATH variable was undocumented, but it is not needed anymore. It was used before the existence of the go tool to tell cgo the full path of the package that it was building, which in turn set the name of the shared library that cgo expected to load back when cgo used shared libraries. CGOPKGPATH no longer does anything useful; it just affects the comments in the generated header file. Remove it to avoid any future confusion. Fixes #11852 Change-Id: Ieb452e5bbcfd05b87a4a3618b5b8f44423341858 Reviewed-on: https://go-review.googlesource.com/15266Reviewed-by:
-
Brad Fitzpatrick authored
Commit acc90c53 passed the trybots, lingered for weeks, and in the meantime the type of this variable changed to a bool. I didn't rebase and re-run the trybots before submitting. Fixes #12832 Change-Id: If24fda227edd8207f8069c67f1c45f08e6ac215a Reviewed-on: https://go-review.googlesource.com/15286Reviewed-by:
-
Damian Gryski authored
Change-Id: I46c12aaaf453365c157604dfb1486605cfefd7af Reviewed-on: https://go-review.googlesource.com/15263Reviewed-by:
-
Ilya Tocar authored
Use SSE 4.1 rounding instruction to perform rounding Results (haswell): name old time/op new time/op delta Floor-48 2.71ns ± 0% 1.87ns ± 1% -31.17% (p=0.000 n=16+19) Ceil-48 3.09ns ± 3% 2.16ns ± 0% -30.16% (p=0.000 n=19+12) Change-Id: If63715879eed6530b1eb4fc96132d827f8f43909 Reviewed-on: https://go-review.googlesource.com/14561Reviewed-by:
Klaus Post <klauspost@gmail.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
acanino authored
Internal error arose from calling methodfunc on a invalid interface field during the implements check. int obviously isn't a function, and errors on getinarg... for im := iface.Type; im != nil; im = im.Down { imtype = methodfunc(im.Type, nil) // ... } Fix handles the internal compiler error, but does not throw an additional error, i.e. the following code will error on the I interface, but type A will pass the implements check since 'Read(string) string' is implemented and 'int' is skipped type I interface { Read(string) string int } type A struct { } func (a *A) Read(s string) string { return s } func New() I { return new(A) } Fixes #10975 Change-Id: I4b54013afb2814db3f315515f0c742d8631ca500 Reviewed-on: https://go-review.googlesource.com/13747 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Austin Clements authored
Change-Id: I8da1c7a86adf6672e5e5c44cbab422706833c1da Reviewed-on: https://go-review.googlesource.com/15350Reviewed-by:
-
- 02 Oct, 2015 14 commits
-
-
Austin Clements authored
Currently, amd64p32's memmove and memclr use 8 byte writes as much as possible and 1 byte writes for the tail of the object. However, if an object ends with a 4 byte pointer at an 8 byte aligned offset, this may copy/zero the pointer field one byte at a time, allowing the garbage collector to observe a partially copied pointer. Fix this by using 4 byte writes instead of 8 byte writes. Updates #12552. Change-Id: I13324fd05756fb25ae57e812e836f0a975b5595c Reviewed-on: https://go-review.googlesource.com/15370 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
This fixes an issue where the runtime panics with "out of memory" or "cannot allocate memory" even though there's ample memory by reducing the number of memory mappings created by the memory allocator. Commit 7e1b61c7 worked around issue #8832 where Linux's transparent huge page support could dramatically increase the RSS of a Go process by setting the MADV_NOHUGEPAGE flag on any regions of pages released to the OS with MADV_DONTNEED. This had the side effect of also increasing the number of VMAs (memory mappings) in a Go address space because a separate VMA is needed for every region of the virtual address space with different flags. Unfortunately, by default, Linux limits the number of VMAs in an address space to 65530, and a large heap can quickly reach this limit when the runtime starts scavenging memory. This commit dramatically reduces the number of VMAs. It does this primarily by only adjusting the huge page flag at huge page granularity. With this change, on amd64, even a pessimal heap that alternates between MADV_NOHUGEPAGE and MADV_HUGEPAGE must reach 128GB to reach the VMA limit. Because of this rounding to huge page granularity, this change is also careful to leave large used and unused regions huge page-enabled. This change reduces the maximum number of VMAs during the runtime benchmarks with GODEBUG=scavenge=1 from 692 to 49. Fixes #12233. Change-Id: Ic397776d042f20d53783a1cacf122e2e2db00584 Reviewed-on: https://go-review.googlesource.com/15191Reviewed-by:
-
Austin Clements authored
In general, finishsweep_m must block until any spans that are concurrently being swept have been swept. It accomplishes this by looping over all spans, which, as in the previous commit, takes ~1ms/heap GB. Unfortunately, we do this during the STW sweep termination phase, so multi-gigabyte heaps can push our STW time past 10ms. However, there's no need to do this wait if the world is stopped because, in effect, stopping the world already had to wait for anything that was sweeping (and if it didn't, the wait in finishsweep_m would deadlock). Hence, we can simply skip this loop if the world is stopped, such as during sweep termination. In fact, currently all calls to finishsweep_m are STW, but this hasn't always been the case and may not be the case in the future, so we keep the logic around. For 24GB heaps, this reduces max pause time by 75% relative to tip and by 90% relative to Go 1.5. Notably, all pauses are now well under 10ms. Here are the results for the garbage benchmark: ------------- max pause ------------ Heap Procs after change before change 1.5.1 24GB 12 3.8ms 16ms 37ms 24GB 4 3.7ms 16ms 37ms 4GB 4 3.7ms 3ms 6.9ms In the 4GB/4P case, it seems the "before change" run got lucky: the max went up, but the 99%ile pause time went down from 3ms to 2.04ms. Change-Id: Ica22189559f231d408ef2815019c9dbb5f38bf31 Reviewed-on: https://go-review.googlesource.com/15071Reviewed-by:Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
In order to compute the sweep ratio, the runtime needs to know how many pages belong to spans in state _MSpanInUse. Currently it finds this out by looping over all spans during mark termination. However, this takes ~1ms/heap GB, so multi-gigabyte heaps can quickly push our STW time past 10ms. Replace the loop with an actively maintained count of in-use pages. For multi-gigabyte heaps, this reduces max mark termination pause time by 75%–90% relative to tip and by 85%–95% relative to Go 1.5.1. This shifts the longest pause time for large heaps to the sweep termination phase, so it only slightly decreases max pause time, though it roughly halves mean pause time. Here are the results for the garbage benchmark: ---- max mark termination pause ---- Heap Procs after change before change 1.5.1 24GB 12 1.9ms 18ms 37ms 24GB 4 3.7ms 18ms 37ms 4GB 4 920µs 3.8ms 6.9ms Fixes #11484. Change-Id: Ia2d28bb8a1e4f1c3b8ebf79fb203f12b9bf114ac Reviewed-on: https://go-review.googlesource.com/15070Reviewed-by: -
Austin Clements authored
This reduces pause time by ~25% relative to tip and by ~50% relative to Go 1.5.1. Currently one of the steps of STW mark termination is to loop (in parallel) over all spans to find objects with finalizers in order to mark all objects reachable from these objects and to treat the finalizer special as a root. Unfortunately, even if there are no finalizers at all, this loop takes roughly 1 ms/heap GB/core, so multi-gigabyte heaps can quickly push our STW time past 10ms. Fix this by moving this scan from mark termination to concurrent scan, where it can run in parallel with mutators. The loop itself could also be optimized, but this cost is small compared to concurrent marking. Making this scan concurrent introduces two complications: 1) The scan currently walks the specials list of each span without locking it, which is safe only with the world stopped. We fix this by speculatively checking if a span has any specials (the vast majority won't) and then locking the specials list only if there are specials to check. 2) An object can have a finalizer set after concurrent scan, in which case it won't have been marked appropriately by concurrent scan. If the finalizer is a closure and is only reachable from the special, it could be swept before it is run. Likewise, if the object is not marked yet when the finalizer is set and then becomes unreachable before it is marked, other objects reachable only from it may be swept before the finalizer function is run. We fix this issue by making addfinalizer ensure the same marking invariants as markroot does. For multi-gigabyte heaps, this reduces max pause time by 20%–30% relative to tip (depending on GOMAXPROCS) and by ~50% relative to Go 1.5.1 (where this loop was neither concurrent nor parallel). Here are the results for the garbage benchmark: ---------------- max pause ---------------- Heap Procs Concurrent scan STW parallel scan 1.5.1 24GB 12 18ms 23ms 37ms 24GB 4 18ms 25ms 37ms 4GB 4 3.8ms 4.9ms 6.9ms In all cases, 95%ile pause time is similar to the max pause time. This also improves mean STW time by 10%–30%. Fixes #11485. Change-Id: I9359d8c3d120a51d23d924b52bf853a1299b1dfd Reviewed-on: https://go-review.googlesource.com/14982Reviewed-by: -
Austin Clements authored
Currently, the GC modes constants are untyped and functions pass them around as ints. Clean this up by introducing a proper type for these constant. Change-Id: Ibc022447bdfa203644921fbb548312d7e2272e8d Reviewed-on: https://go-review.googlesource.com/14981Reviewed-by:
-
Austin Clements authored
Change-Id: I3c21ffa80a5c14911e07238b1f64bec686ed7b72 Reviewed-on: https://go-review.googlesource.com/14980Reviewed-by:
-
Brad Fitzpatrick authored
Update #12815 Change-Id: I3bf6de74bc8ab07000fe9a4308299839ef20632f Reviewed-on: https://go-review.googlesource.com/15283Reviewed-by:
Evan Brown <evanbrown@google.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
-
Robert Griesemer authored
Removed direct link to issue tracker in the README - it makes it too easy to use it for a question - and it's abused multiple times a day for questions. It's easy enough to find it if there's a real issue to report. Added sentence to point people at golang-nuts and the new forum. Change-Id: If75bab888cda064aceeefc49ef672fbb964f8f54 Reviewed-on: https://go-review.googlesource.com/15284Reviewed-by:
Jason Buberel <jbuberel@google.com> Reviewed-by:
-
Ian Gudger authored
Fixes a case where the Stmt.Close() function in database/sql discards any error generated by the Close() function of the contained driverStmt. Fixes #12798 Change-Id: I40384d6165856665b062d15a643e4ecc09d63fda Reviewed-on: https://go-review.googlesource.com/15178Reviewed-by:
-
Ian Lance Taylor authored
I've tested with clang 3.6. The builder is running 3.5, and fails. Fixes #12814. Change-Id: I087fb75c3a24bed7f7fa5e9d7a1444590a316d63 Reviewed-on: https://go-review.googlesource.com/15259Reviewed-by:
-
David Crawshaw authored
Change-Id: Ic22597b5e2824cffe9598cb9b506af3426c285fd Reviewed-on: https://go-review.googlesource.com/12412 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Michael Hudson-Doyle authored
Issue #12552 can happen on ppc64 too, although much less frequently in my testing. I'm fairly sure this fixes it (2 out of 200 runs of oracle.test failed without this change and 0 of 200 failed with it). It's also a lot faster for large moves/clears: name old speed new speed delta Memmove1-6 157MB/s ± 9% 144MB/s ± 0% -8.20% (p=0.004 n=10+9) Memmove2-6 281MB/s ± 1% 249MB/s ± 1% -11.53% (p=0.000 n=10+10) Memmove3-6 376MB/s ± 1% 328MB/s ± 1% -12.64% (p=0.000 n=10+10) Memmove4-6 475MB/s ± 4% 345MB/s ± 1% -27.28% (p=0.000 n=10+8) Memmove5-6 540MB/s ± 1% 393MB/s ± 0% -27.21% (p=0.000 n=10+10) Memmove6-6 609MB/s ± 0% 423MB/s ± 0% -30.56% (p=0.000 n=9+10) Memmove7-6 659MB/s ± 0% 468MB/s ± 0% -28.99% (p=0.000 n=8+10) Memmove8-6 705MB/s ± 0% 1295MB/s ± 1% +83.73% (p=0.000 n=9+9) Memmove9-6 740MB/s ± 1% 1241MB/s ± 1% +67.61% (p=0.000 n=10+8) Memmove10-6 780MB/s ± 0% 1162MB/s ± 1% +48.95% (p=0.000 n=10+9) Memmove11-6 811MB/s ± 0% 1180MB/s ± 0% +45.58% (p=0.000 n=8+9) Memmove12-6 820MB/s ± 1% 1073MB/s ± 1% +30.83% (p=0.000 n=10+9) Memmove13-6 849MB/s ± 0% 1068MB/s ± 1% +25.87% (p=0.000 n=10+10) Memmove14-6 877MB/s ± 0% 911MB/s ± 0% +3.83% (p=0.000 n=10+10) Memmove15-6 893MB/s ± 0% 922MB/s ± 0% +3.25% (p=0.000 n=10+9) Memmove16-6 897MB/s ± 1% 2418MB/s ± 1% +169.67% (p=0.000 n=10+9) Memmove32-6 908MB/s ± 0% 3927MB/s ± 2% +332.64% (p=0.000 n=10+8) Memmove64-6 1.11GB/s ± 0% 5.59GB/s ± 0% +404.64% (p=0.000 n=9+9) Memmove128-6 1.25GB/s ± 0% 6.71GB/s ± 2% +437.49% (p=0.000 n=9+10) Memmove256-6 1.33GB/s ± 0% 7.25GB/s ± 1% +445.06% (p=0.000 n=10+10) Memmove512-6 1.38GB/s ± 0% 8.87GB/s ± 0% +544.43% (p=0.000 n=10+10) Memmove1024-6 1.40GB/s ± 0% 10.00GB/s ± 0% +613.80% (p=0.000 n=10+10) Memmove2048-6 1.41GB/s ± 0% 10.65GB/s ± 0% +652.95% (p=0.000 n=9+10) Memmove4096-6 1.42GB/s ± 0% 11.01GB/s ± 0% +675.37% (p=0.000 n=8+10) Memclr5-6 269MB/s ± 1% 264MB/s ± 0% -1.80% (p=0.000 n=10+10) Memclr16-6 600MB/s ± 0% 887MB/s ± 1% +47.83% (p=0.000 n=10+10) Memclr64-6 1.06GB/s ± 0% 2.91GB/s ± 1% +174.58% (p=0.000 n=8+10) Memclr256-6 1.32GB/s ± 0% 6.58GB/s ± 0% +399.86% (p=0.000 n=9+10) Memclr4096-6 1.42GB/s ± 0% 10.90GB/s ± 0% +668.03% (p=0.000 n=8+10) Memclr65536-6 1.43GB/s ± 0% 11.37GB/s ± 0% +697.83% (p=0.000 n=9+8) GoMemclr5-6 359MB/s ± 0% 360MB/s ± 0% +0.46% (p=0.000 n=10+10) GoMemclr16-6 750MB/s ± 0% 1264MB/s ± 1% +68.45% (p=0.000 n=10+10) GoMemclr64-6 1.17GB/s ± 0% 3.78GB/s ± 1% +223.58% (p=0.000 n=10+9) GoMemclr256-6 1.35GB/s ± 0% 7.47GB/s ± 0% +452.44% (p=0.000 n=10+10) Update #12552 Change-Id: I7192e9deb9684a843aed37f58a16a4e29970e893 Reviewed-on: https://go-review.googlesource.com/14840Reviewed-by:
-
Mikio Hara authored
This change splits signal_unix.go into signal_unix.go and signal2_unix.go and removes the fake symbol sigfwd from signal forwarding unsupported platforms for clarification purpose. Change-Id: I205eab5cf1930fda8a68659b35cfa9f3a0e67ca6 Reviewed-on: https://go-review.googlesource.com/12062Reviewed-by:
-
- 01 Oct, 2015 1 commit
-
-
Joe Tsai authored
If the stream is in an inconsistent state, it does not make sense that Reader.Read can be called and possibly succeed. Change-Id: I9d1c5a1300b2c2b45232188aa7999e350809dcf2 Reviewed-on: https://go-review.googlesource.com/15177Reviewed-by:
-
