- 21 Apr, 2016 21 commits
-
-
Matthew Dempsky authored
Instead of using TARRAY for both arrays and slices, create a new TSLICE kind to handle slices. Also, get rid of the "DDDArray" distinction. While kinda ugly, it seems likely we'll need to defer evaluating the constant bounds expressions for golang.org/issue/13890. Passes toolstash/buildall. Change-Id: I8e45d4900e7df3a04cce59428ec8b38035d3cc3a Reviewed-on: https://go-review.googlesource.com/22329Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
- adjusted example code - fixed comments Fixes #14785. Change-Id: Ia757dc93b0a69b8408559885ece7f3685a37daaa Reviewed-on: https://go-review.googlesource.com/22353Reviewed-by: Rob Pike <r@golang.org>
-
Austin Clements authored
Currently when we compute the trigger for the next GC, we do it based on an estimate of the reachable heap size at the start of the GC cycle, which is itself based on an estimate of the floating garbage. This was introduced by 4655aadd to fix a bad feedback loop that allowed the heap to grow to many times the true reachable size. However, this estimate gets easily confused by rapidly allocating applications, and, worse it's different than the heap size the trigger controller uses to compute the trigger itself. This results in the trigger controller often thinking that GC finished before it started. Since this would be a pretty great outcome from it's perspective, it sets the trigger for the next cycle as close to the next goal as possible (which is limited to 95% of the goal). Furthermore, the bad feedback loop this estimate originally fixed seems not to happen any more, suggesting it was fixed more correctly by some other change in the mean time. Finally, with the change to allocate black, it shouldn't even be theoretically possible for this bad feedback loop to occur. Hence, eliminate the floating garbage estimate and simply consider the reachable heap to be the marked heap. This harms overall throughput slightly for allocation-heavy benchmarks, but significantly improves mutator availability. Fixes #12204. This brings the average trigger in this benchmark from 0.95 (the cap) to 0.7 and the active GC utilization from ~90% to ~45%. Updates #14951. This makes the trigger controller much better behaved, so it pulls the trigger lower if assists are consuming a lot of CPU like it's supposed to, increasing mutator availability. name old time/op new time/op delta XBenchGarbage-12 2.21ms ± 1% 2.28ms ± 3% +3.29% (p=0.000 n=17+17) Some of this slow down we paid for in earlier commits. Relative to the start of the series to switch to allocate-black (the parent of "count black allocations toward scan work"), the garbage benchmark is 2.62% slower. name old time/op new time/op delta BinaryTree17-12 2.53s ± 3% 2.53s ± 3% ~ (p=0.708 n=20+19) Fannkuch11-12 2.08s ± 0% 2.08s ± 0% -0.22% (p=0.002 n=19+18) FmtFprintfEmpty-12 45.3ns ± 2% 45.2ns ± 3% ~ (p=0.505 n=20+20) FmtFprintfString-12 129ns ± 0% 131ns ± 2% +1.80% (p=0.000 n=16+19) FmtFprintfInt-12 121ns ± 2% 121ns ± 2% ~ (p=0.768 n=19+19) FmtFprintfIntInt-12 186ns ± 1% 188ns ± 3% +0.99% (p=0.000 n=19+19) FmtFprintfPrefixedInt-12 188ns ± 1% 188ns ± 1% ~ (p=0.947 n=18+16) FmtFprintfFloat-12 254ns ± 1% 255ns ± 1% +0.30% (p=0.002 n=19+17) FmtManyArgs-12 763ns ± 0% 770ns ± 0% +0.92% (p=0.000 n=18+18) GobDecode-12 7.00ms ± 1% 7.04ms ± 1% +0.61% (p=0.049 n=20+20) GobEncode-12 5.88ms ± 1% 5.88ms ± 0% ~ (p=0.641 n=18+19) Gzip-12 214ms ± 1% 215ms ± 1% +0.43% (p=0.002 n=18+19) Gunzip-12 37.6ms ± 0% 37.6ms ± 0% +0.11% (p=0.015 n=17+18) HTTPClientServer-12 76.9µs ± 2% 78.1µs ± 2% +1.44% (p=0.000 n=20+18) JSONEncode-12 15.2ms ± 2% 15.1ms ± 1% ~ (p=0.271 n=19+18) JSONDecode-12 53.1ms ± 1% 53.3ms ± 0% +0.49% (p=0.000 n=18+19) Mandelbrot200-12 4.04ms ± 1% 4.03ms ± 0% -0.33% (p=0.005 n=18+18) GoParse-12 3.29ms ± 1% 3.28ms ± 1% ~ (p=0.146 n=16+17) RegexpMatchEasy0_32-12 69.9ns ± 3% 69.5ns ± 1% ~ (p=0.785 n=20+19) RegexpMatchEasy0_1K-12 237ns ± 0% 237ns ± 0% ~ (p=1.000 n=18+18) RegexpMatchEasy1_32-12 69.5ns ± 1% 69.2ns ± 1% -0.44% (p=0.020 n=16+19) RegexpMatchEasy1_1K-12 372ns ± 1% 371ns ± 2% ~ (p=0.086 n=20+19) RegexpMatchMedium_32-12 108ns ± 3% 107ns ± 1% -1.00% (p=0.004 n=19+14) RegexpMatchMedium_1K-12 34.2µs ± 4% 34.0µs ± 2% ~ (p=0.380 n=19+20) RegexpMatchHard_32-12 1.77µs ± 4% 1.76µs ± 3% ~ (p=0.558 n=18+20) RegexpMatchHard_1K-12 53.4µs ± 4% 52.8µs ± 2% -1.10% (p=0.020 n=18+20) Revcomp-12 359ms ± 4% 377ms ± 0% +5.19% (p=0.000 n=20+18) Template-12 63.7ms ± 2% 62.9ms ± 2% -1.27% (p=0.005 n=18+20) TimeParse-12 316ns ± 2% 313ns ± 1% ~ (p=0.059 n=20+16) TimeFormat-12 329ns ± 0% 331ns ± 0% +0.39% (p=0.000 n=16+18) [Geo mean] 51.6µs 51.7µs +0.18% Change-Id: I1dce4640c8205d41717943b021039fffea863c57 Reviewed-on: https://go-review.googlesource.com/21324Reviewed-by: Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently we allocate white for most of concurrent marking. This is based on the classical argument that it produces less floating garbage, since allocations during GC may not get linked into the heap and allocating white lets us reclaim these. However, it's not clear how often this actually happens, especially since our write barrier shades any pointer as soon as it's installed in the heap regardless of the color of the slot. On the other hand, allocating black has several advantages that seem to significantly outweigh this downside. 1) It naturally bounds the total scan work to the live heap size at the start of a GC cycle. Allocating white does not, and thus depends entirely on assists to prevent the heap from growing faster than it can be scanned. 2) It reduces the total amount of scan work per GC cycle by the size of newly allocated objects that are linked into the heap graph, since objects allocated black never need to be scanned. 3) It reduces total write barrier work since more objects will already be black when they are linked into the heap graph. This gives a slight overall improvement in benchmarks. name old time/op new time/op delta XBenchGarbage-12 2.24ms ± 0% 2.21ms ± 1% -1.32% (p=0.000 n=18+17) name old time/op new time/op delta BinaryTree17-12 2.60s ± 3% 2.53s ± 3% -2.56% (p=0.000 n=20+20) Fannkuch11-12 2.08s ± 1% 2.08s ± 0% ~ (p=0.452 n=19+19) FmtFprintfEmpty-12 45.1ns ± 2% 45.3ns ± 2% ~ (p=0.367 n=19+20) FmtFprintfString-12 131ns ± 3% 129ns ± 0% -1.60% (p=0.000 n=20+16) FmtFprintfInt-12 122ns ± 0% 121ns ± 2% -0.86% (p=0.000 n=16+19) FmtFprintfIntInt-12 187ns ± 1% 186ns ± 1% ~ (p=0.514 n=18+19) FmtFprintfPrefixedInt-12 189ns ± 0% 188ns ± 1% -0.54% (p=0.000 n=16+18) FmtFprintfFloat-12 256ns ± 0% 254ns ± 1% -0.43% (p=0.000 n=17+19) FmtManyArgs-12 769ns ± 0% 763ns ± 0% -0.72% (p=0.000 n=18+18) GobDecode-12 7.08ms ± 2% 7.00ms ± 1% -1.22% (p=0.000 n=20+20) GobEncode-12 5.88ms ± 0% 5.88ms ± 1% ~ (p=0.406 n=18+18) Gzip-12 214ms ± 0% 214ms ± 1% ~ (p=0.103 n=17+18) Gunzip-12 37.6ms ± 0% 37.6ms ± 0% ~ (p=0.563 n=17+17) HTTPClientServer-12 77.2µs ± 3% 76.9µs ± 2% ~ (p=0.606 n=20+20) JSONEncode-12 15.1ms ± 1% 15.2ms ± 2% ~ (p=0.138 n=19+19) JSONDecode-12 53.3ms ± 1% 53.1ms ± 1% -0.33% (p=0.000 n=19+18) Mandelbrot200-12 4.04ms ± 1% 4.04ms ± 1% ~ (p=0.075 n=19+18) GoParse-12 3.30ms ± 1% 3.29ms ± 1% -0.57% (p=0.000 n=18+16) RegexpMatchEasy0_32-12 69.5ns ± 1% 69.9ns ± 3% ~ (p=0.822 n=18+20) RegexpMatchEasy0_1K-12 237ns ± 1% 237ns ± 0% ~ (p=0.398 n=19+18) RegexpMatchEasy1_32-12 69.8ns ± 2% 69.5ns ± 1% ~ (p=0.090 n=20+16) RegexpMatchEasy1_1K-12 371ns ± 1% 372ns ± 1% ~ (p=0.178 n=19+20) RegexpMatchMedium_32-12 108ns ± 2% 108ns ± 3% ~ (p=0.124 n=20+19) RegexpMatchMedium_1K-12 33.9µs ± 2% 34.2µs ± 4% ~ (p=0.309 n=20+19) RegexpMatchHard_32-12 1.75µs ± 2% 1.77µs ± 4% +1.28% (p=0.018 n=19+18) RegexpMatchHard_1K-12 52.7µs ± 1% 53.4µs ± 4% +1.23% (p=0.013 n=15+18) Revcomp-12 354ms ± 1% 359ms ± 4% +1.27% (p=0.043 n=20+20) Template-12 63.6ms ± 2% 63.7ms ± 2% ~ (p=0.654 n=20+18) TimeParse-12 313ns ± 1% 316ns ± 2% +0.80% (p=0.014 n=17+20) TimeFormat-12 332ns ± 0% 329ns ± 0% -0.66% (p=0.000 n=16+16) [Geo mean] 51.7µs 51.6µs -0.09% Change-Id: I2214a6a0e4f544699ea166073249a8efdf080dc0 Reviewed-on: https://go-review.googlesource.com/21323Reviewed-by: Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently allocating black switches to the system stack (which is probably a historical accident) and atomically updates the global bytes marked stat. Since we're about to depend on this much more, optimize it a bit by putting it back on the regular stack and updating the per-P bytes marked stat, which gets lazily folded into the global bytes marked stat. Change-Id: Ibbe16e5382d3fd2256e4381f88af342bf7020b04 Reviewed-on: https://go-review.googlesource.com/22170Reviewed-by: Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently we count black allocations toward the scannable heap size, but not toward the scan work we've done so far. This is clearly inconsistent (we have, in effect, scanned these allocations and since they're already black, we're not going to scan them again). Worse, it means we don't count black allocations toward the scannable heap size as of the *next* GC because this is based on the amount of scan work we did in this cycle. Fix this by counting black allocations as scan work. Currently the GC spends very little time in allocate-black mode, so this probably hasn't been a problem, but this will become important when we switch to always allocating black. Change-Id: If6ff693b070c385b65b6ecbbbbf76283a0f9d990 Reviewed-on: https://go-review.googlesource.com/22119Reviewed-by: Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Marcel van Lohuizen authored
Allows passing regexps per subtest to --test.run and --test.bench Note that the documentation explicitly states that the split regular expressions match the correpsonding parts (path components) of the bench/test identifier. This is intended and slightly different from the i'th RE matching the subtest/subbench at the respective level. Picking this semantics allows guaranteeing that a test or benchmark identifier as printed by go test can be passed verbatim (possibly quoted) to, respectively, -run or -bench: subtests and subbenches might have a '/' in their name, causing a misaligment if their ID is passed to -run or -bench as is. This semantics has other benefits, but this is the main motivation. Fixes golang.go#15126 Change-Id: If72e6d3f54db1df6bc2729ac6edc7ab3c740e7c3 Reviewed-on: https://go-review.googlesource.com/19122Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Marcel van Lohuizen <mpvl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
Fixes noopt builder. Change-Id: If13373b2597f0fcc9b1b2f9c860f2bd043e43c6c Reviewed-on: https://go-review.googlesource.com/22338Reviewed-by: Keith Randall <khr@golang.org>
-
Cherry Zhang authored
Progress on SSA backend for ARM. Still not complete. It compiles a Fibonacci function, but the caller picked the return value from an incorrect offset. This CL adjusts it to match the stack frame layout for architectures with link register. Updates #15365. Change-Id: I01e03c3e95f5503a185e8ac2b6d9caf4faf3d014 Reviewed-on: https://go-review.googlesource.com/22186Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Cherry Zhang authored
Progress on SSA for ARM. Still not complete. Now Fibonacci function compiles and runs correctly. The old backend swaps the operands for CMP instruction. This CL does the same on SSA backend, and uses conditional branch accordingly. Updates #15365. Change-Id: I117e17feb22f03d936608bd232f76970e4bbe21a Reviewed-on: https://go-review.googlesource.com/22187Reviewed-by: Keith Randall <khr@golang.org>
-
David Crawshaw authored
Updates #15374 Change-Id: I3ea715735862fe9550b88d7a29def6cb9d4419a6 Reviewed-on: https://go-review.googlesource.com/22243 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
-
David Crawshaw authored
Reduces link time for cmd/go by 1%. Change-Id: Iad4a16db0aedc56f81ddf73ba9b632e418dc1b19 Reviewed-on: https://go-review.googlesource.com/22242Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alex Brainman authored
cmd/link reads PE object files when building programs with cgo. cmd/link accesses object relocations. Add new Section.Relocs that provides similar functionality in debug/pe. Updates #15345 Change-Id: I34de91b7f18cf1c9e4cdb3aedd685486a625ac92 Reviewed-on: https://go-review.googlesource.com/22332 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
-
Keith Randall authored
Disable phielimValue from rewrite pass for now. Change-Id: I9f3bb1f527b50bc7a21cc6b7cb89f6136efd81e8 Reviewed-on: https://go-review.googlesource.com/22335 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Martin Möhrmann authored
Consistently use type int for the size argument of runtime.newarray, runtime.reflect_unsafe_NewArray and reflect.unsafe_NewArray. Change-Id: Ic77bf2dde216c92ca8c49462f8eedc0385b6314e Reviewed-on: https://go-review.googlesource.com/22311Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Martin Möhrmann <martisch@uos.de> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
Ancestor comparison was the wrong way around, effectively disabling the def-must-dominate-use check. Update #15084 Change-Id: Ic56d674c5000569d2cc855bbb000a60eae517c7c Reviewed-on: https://go-review.googlesource.com/22330 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
David Crawshaw authored
For the Solaris and S/390 builders. Change-Id: Id9a83e0df91e6d0df8488ec5e2a546ba8e2d800e Reviewed-on: https://go-review.googlesource.com/22327 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by: Michael Munday <munday@ca.ibm.com>
-
Alex Brainman authored
Updates #15345 Change-Id: If1fca1f6042571cb0ac689bbb3c294309dd6e7b4 Reviewed-on: https://go-review.googlesource.com/22331Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alex Brainman authored
Introduce (*SectionHeader32).fullName and add documentation comments. Updates #15345 Change-Id: I8f3b8ab9492642d62e7aad010c91c68daea3f14b Reviewed-on: https://go-review.googlesource.com/22301Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Tal Shprecher authored
Fixes #14729 Change-Id: Ied819aa7b23e25de30aa8cde049c97297b4cab11 Reviewed-on: https://go-review.googlesource.com/22325Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
Test with forceNewExport set to true (but continues to be disabled by default for now). Fixes #15322. Change-Id: I3b893db2206cbb79e66339284f22f4a0b20bf137 Reviewed-on: https://go-review.googlesource.com/22328Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
- 20 Apr, 2016 19 commits
-
-
David Crawshaw authored
First (and largest single) step to switching cmd/link from linked lists of symbols to slices. Sort sections independently and concurrently. This reduces jujud link times on linux/amd64 by ~4%. Updates #15374 Change-Id: I452bc8f33081039468636502fe3c1cc8d6ed9efa Reviewed-on: https://go-review.googlesource.com/22205Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
-
David Crawshaw authored
(Split out from CL 22205.) Change-Id: I45838dda8ea8c451b4388b8aade2c209cde2c0e1 Reviewed-on: https://go-review.googlesource.com/22299Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Lynn Boger authored
This change improves the performance of the block function used within crypto/md5 on ppc64le. The following improvement was seen: BenchmarkHash8Bytes 8.39 26.04 3.10x BenchmarkHash1K 99.41 407.84 4.10x BenchmarkHash8K 108.87 460.00 4.23x BenchmarkHash8BytesUnaligned 8.39 25.80 3.08x BenchmarkHash1KUnaligned 89.94 407.81 4.53x BenchmarkHash8KUnaligned 96.57 459.22 4.76x Fixes #15385 Change-Id: I8af5af089cc3e3740c33c662003d104de5fe1d1b Reviewed-on: https://go-review.googlesource.com/22294 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
Follow-up to https://golang.org/cl/21755. This turned out to be a bit more than just a few nits as originally expected in that CL. 1) The actual mantissa may be shorter than required for the given precision (because of trailing 0's): no need to allocate space for it (and transmit 0's). This can save a lot of space when the precision is high: E.g., for prec == 1000, 16 words or 128 bytes are required at the most, but if the actual number is short, it may be much less (for the test cases present, it's significantly less). 2) The actual mantissa may be longer than the number of words required for the given precision: make sure to not overflow when encoding in bytes. 3) Add more documentation. 4) Add more tests. Change-Id: I9f40c408cfdd9183a8e81076d2f7d6c75e7a00e9 Reviewed-on: https://go-review.googlesource.com/22324Reviewed-by: Alan Donovan <adonovan@google.com>
-
Keith Randall authored
mapaccess{1,2} returns a pointer to the value. When the key is not in the map, it returns a pointer to zeroed memory. Currently, for large map values we have a complicated scheme which dynamically allocates zeroed memory for this purpose. It is ugly code and requires an atomic.Load in a bunch of places we'd rather not have it. Switch to a scheme where callsites of mapaccess{1,2} which expect large return values pass in a pointer to zeroed memory that mapaccess can return if the key is not found. This avoids the atomic.Load on all map accesses with a few extra instructions only for the large value acccesses, plus a bit of bss space. There was a time (1.4 & 1.5?) where we did something like this but all the tricks to make the right size zero value were done by the linker. That scheme broke in the presence of dyamic linking. The scheme in this CL works even when dynamic linking. Fixes #12337 Change-Id: Ic2d0319944af33bbb59785938d9ab80958d1b4b1 Reviewed-on: https://go-review.googlesource.com/22221 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Rob Pike authored
A late response to CL 22163. Change-Id: I5275a22af7081875af0256da296811f4fe9832dc Reviewed-on: https://go-review.googlesource.com/22296Reviewed-by: David Symonds <dsymonds@golang.org>
-
David Crawshaw authored
(Split out from CL 22243.) Change-Id: I07709a0c417e7a57e839e5085a37db7d5fbf3a35 Reviewed-on: https://go-review.googlesource.com/22322 Run-TryBot: David Crawshaw <crawshaw@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
David Crawshaw authored
(Split out from CL 22243.) Change-Id: Idac1748c8db2b2ed0484e4afadb105c471c6ce34 Reviewed-on: https://go-review.googlesource.com/22321Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Crawshaw authored
(Split out from CL 22205.) Change-Id: Id32698f48ce02b55c15b6f2842215e0ffdbf425b Reviewed-on: https://go-review.googlesource.com/22298Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
OneOfOne authored
Added GobEncode/Decode and a test for them. Fixes #14593 Change-Id: Ic8d3efd24d0313a1a66f01da293c4c1fd39764a8 Reviewed-on: https://go-review.googlesource.com/21755Reviewed-by: Robert Griesemer <gri@golang.org>
-
David Crawshaw authored
(Split out from CL 22205.) Change-Id: Iab66ac2a1cd3716966d8e59c570931bce95aba9b Reviewed-on: https://go-review.googlesource.com/22297Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Munday authored
Adds support for single block encryption using the cipher message (KM) instruction. KM handles key expansion internally and therefore it is not done up front when using the assembly implementation on s390x. Change-Id: I69954b8ae36d549e1dc40d7acd5a10bedfaaef9c Reviewed-on: https://go-review.googlesource.com/22194 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bill O'Farrell <billotosyr@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Keith Randall authored
Improve forward-looking desired register calculations. It is now inter-block and handles a bunch more cases. Fixes #14504 Fixes #14828 Fixes #15254 Change-Id: Ic240fa0ec6a779d80f577f55c8a6c4ac8c1a940a Reviewed-on: https://go-review.googlesource.com/22160 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Jamil Djadala authored
In BenchmarkDup fuction, heap is created as h := make(myHeap, n) and then n elements are added, so first time there are 2*n elements in heap. Fixes #15380 Change-Id: I0508486a847006b3cd545fd695e8b09af339134f Reviewed-on: https://go-review.googlesource.com/22310Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
mallocgc can calculate noscan itself. The only remaining flag argument is needzero, so we just make that a boolean arg. Fixes #15379 Change-Id: I839a70790b2a0c9dbcee2600052bfbd6c8148e20 Reviewed-on: https://go-review.googlesource.com/22290Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alex Brainman authored
Just moving code. No code changes. Updates #15345 Change-Id: I89c257b7aae4fbd78ce59a42909ecb3ff493659d Reviewed-on: https://go-review.googlesource.com/22300Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alex Brainman authored
PE specification requires that long section and symbol names are stored in PE string table. Introduce StringTable that implements this functionality. Only string table reading is implemented. Updates #15345 Change-Id: Ib9638617f2ab1881ad707111d96fc68b0e47340e Reviewed-on: https://go-review.googlesource.com/22181 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
-
Alex Brainman authored
No code changes. Just moved ImportDirectory next to ImportedSymbols. And moved useless FormatError to the bottom of file.go. Updates #15345 Change-Id: I91ff243cefd18008b1c5ee9ec4326583deee431b Reviewed-on: https://go-review.googlesource.com/22182Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
No point in passing the slice type to these functions. All they need is the element type. One less indirection, maybe a few less []T type descriptors in the binary. Change-Id: Ib0b83b5f14ca21d995ecc199ce8ac00c4eb375e6 Reviewed-on: https://go-review.googlesource.com/22275Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-