- 06 Oct, 2015 3 commits
-
-
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:Andrew Gerrand <adg@golang.org>
-
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:
Andrew Gerrand <adg@golang.org>
-
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:
Andrew Gerrand <adg@golang.org>
-
- 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:
Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
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:
Ian Lance Taylor <iant@golang.org>
-
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:
Brad Fitzpatrick <bradfitz@golang.org>
-
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:
Brad Fitzpatrick <bradfitz@golang.org>
-
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:
Keith Randall <khr@golang.org> Reviewed-by:
Minux Ma <minux@golang.org> Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
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:
Minux Ma <minux@golang.org>
-
- 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:
Ian Lance Taylor <iant@golang.org>
-
Shenghou Ma authored
Fixes #12601. Change-Id: I0be69ffe9ba19934aaef1651845c725708db77de Reviewed-on: https://go-review.googlesource.com/14546Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 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 <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
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:
Brad Fitzpatrick <bradfitz@golang.org>
-
Damian Gryski authored
Change-Id: I46c12aaaf453365c157604dfb1486605cfefd7af Reviewed-on: https://go-review.googlesource.com/15263Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
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:
Keith Randall <khr@golang.org>
-
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:
Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
Change-Id: I8da1c7a86adf6672e5e5c44cbab422706833c1da Reviewed-on: https://go-review.googlesource.com/15350Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
- 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:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
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:
Keith Randall <khr@golang.org>
-
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:
Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
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:
Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
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:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Change-Id: I3c21ffa80a5c14911e07238b1f64bec686ed7b72 Reviewed-on: https://go-review.googlesource.com/14980Reviewed-by:
Minux Ma <minux@golang.org>
-
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:
Ian Lance Taylor <iant@golang.org>
-
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:
Brad Fitzpatrick <bradfitz@golang.org>
-
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:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
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:
Brad Fitzpatrick <bradfitz@golang.org>
-
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:
Ian Lance Taylor <iant@golang.org>
-
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:
Minux Ma <minux@golang.org>
-
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:
Ian Lance Taylor <iant@golang.org>
-
- 01 Oct, 2015 8 commits
-
-
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:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Burcu Dogan authored
The native Go host resolver was behaving differently than libc and the entries in the /etc/hosts were handled in a case sensitive way. In order to be compatible with libc's resolver, /etc/hosts lookups must be case-insensitive. Fixes #12806. Change-Id: I3c14001abffadf7458fd1a027c91e6438a87f285 Reviewed-on: https://go-review.googlesource.com/15321 Run-TryBot: Burcu Dogan <jbd@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Alan Donovan authored
Change-Id: Ibd24e1567cb03f7f00f3cbe381bedd6c5215af35 Reviewed-on: https://go-review.googlesource.com/15320Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
David Chase authored
The existing test did not take into account the implicit dereference of &fixedArray and thus heap-escaped when it was not necessary. Also added a detailed test for this and related cases. Fixes #12588 Change-Id: I951e9684a093082ccdca47710f69f4366bd6b3cf Reviewed-on: https://go-review.googlesource.com/15130Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Joel Sing authored
Reduce allocation to avoid running out of memory on the openbsd/arm builder, until issue/12032 is resolved. Update issue #12032 Change-Id: Ibd513829ffdbd0db6cd86a0a5409934336131156 Reviewed-on: https://go-review.googlesource.com/15242Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Joel Sing authored
sysReserve will return nil on failure - correctly handle this case and return nil to the caller. Currently, a failure will result in h.arena_end being set to psize, h.arena_used being set to zero and fun times ensue. On the openbsd/arm builder this has resulted in: runtime: address space conflict: map(0x0) = 0x40946000 fatal error: runtime: address space conflict When it should be reporting out of memory instead. Change-Id: Iba828d5ee48ee1946de75eba409e0cfb04f089d4 Reviewed-on: https://go-review.googlesource.com/15056Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
Jeremy Schlatter authored
Change-Id: I8f22434ade576cc7e3e6d9f357bba12c1296e3d1 Reviewed-on: https://go-review.googlesource.com/15250Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
David Symonds authored
This is a follow-up to a326c3e1 to avoid reflect being in the API. Fixes #12801. Change-Id: Ic4c2e592e2c35b5911f75d88f1d9c44787c80f30 Reviewed-on: https://go-review.googlesource.com/15240 Run-TryBot: David Symonds <dsymonds@golang.org> Reviewed-by:
Andrew Gerrand <adg@golang.org>
-