- 28 Oct, 2015 8 commits
-
-
Michael Hudson-Doyle authored
Change-Id: Iaf9159a68fa395245bc20ccb4a2a377f89371a7e Reviewed-on: https://go-review.googlesource.com/13996Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Michael Hudson-Doyle authored
Fixes #10560 Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122 Reviewed-on: https://go-review.googlesource.com/13991Reviewed-by:
-
Brad Fitzpatrick authored
Adds ReverseProxy.BufferPool for users with sensitive allocation requirements. Permits avoiding 32 KB of io.Copy garbage per request. Fixes #10277 Change-Id: I5dfd58fa70a363ead4be56405e507df90d871719 Reviewed-on: https://go-review.googlesource.com/9399Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David du Colombier authored
In the Go signal handler on Plan 9, when a signal with the _SigThrow flag is received, we call startpanic before printing the stack trace. The startpanic function calls systemstack which calls startpanic_m. In the startpanic_m function, we call allocmcache to allocate _g_.m.mcache. The problem is that allocmcache calls nextSample, which does a floating point operation to return a sampling point for heap profiling. However, Plan 9 doesn't support floating point in the signal handler. This change adds a new function nextSampleNoFP, only called when in the Plan 9 signal handler, which is similar to nextSample, but avoids floating point. Change-Id: Iaa30437aa0f7c8c84d40afbab7567ad3bd5ea2de Reviewed-on: https://go-review.googlesource.com/16307Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: Idc5c4a69919a8ed9d76d4a9cfd9827fb5c59dd11 Reviewed-on: https://go-review.googlesource.com/16389Reviewed-by:
-
Nodir Turakulov authored
Change-Id: I8cc9783fd044bed48347824dcf973c61c78275a5 Reviewed-on: https://go-review.googlesource.com/15833Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Michael Hudson-Doyle authored
The dynamic linker on linux/386 stores the address of the vsyscall helper at a fixed offset from the %gs register on linux/386 for easy access from PIC code. Change-Id: I635305cfecceef2289985d62e676e16810ed6b94 Reviewed-on: https://go-review.googlesource.com/16346Reviewed-by:
-
Michael Hudson-Doyle authored
Change-Id: If3417135ca474468a480b08cf46334fda28f79b4 Reviewed-on: https://go-review.googlesource.com/16345Reviewed-by:
-
- 27 Oct, 2015 4 commits
-
-
Brad Fitzpatrick authored
This part got dropped when we were debating between two solutions in https://golang.org/cl/15151 Fixes #13032 Change-Id: I820b94f6c0c102ccf9342abf957328ea01f49a26 Reviewed-on: https://go-review.googlesource.com/16313Reviewed-by:
Austin Clements <austin@google.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
kargakis authored
Change-Id: I86cdd5c1d7b6f76d3474d180e75ea0c732241080 Reviewed-on: https://go-review.googlesource.com/16309Reviewed-by:
-
Michael Hudson-Doyle authored
Nothing uses this. Change-Id: Ibc13066940bd2ea5c74d955a67f9dc531bef2758 Reviewed-on: https://go-review.googlesource.com/16344Reviewed-by:
-
Matthew Dempsky authored
arena_{start,used,end} are already uintptr, so no need to convert them to uintptr, much less to convert them to unsafe.Pointer and then to uintptr. No binary change to pkg/linux_amd64/runtime.a. Change-Id: Ia4232ed2a724c44fde7eba403c5fe8e6dccaa879 Reviewed-on: https://go-review.googlesource.com/16339Reviewed-by:
-
- 26 Oct, 2015 14 commits
-
-
Robert Griesemer authored
Change-Id: Ia34b6dd099d07d5e1d4bffe775a20fa92705fdb0 Reviewed-on: https://go-review.googlesource.com/16335 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
Change-Id: I956e27fa07f16060b8f41b986d991c36557f7c12 Reviewed-on: https://go-review.googlesource.com/16332Reviewed-by:
-
David du Colombier authored
There is no signal list on Plan 9, since notes are strings. However, some programs expect signals to be defined in the syscall package. Hence, we define a list of the most common notes. Updates #11975. Change-Id: I852e14fd98777c9595a406e04125be1cbebed0fb Reviewed-on: https://go-review.googlesource.com/16301Reviewed-by:
-
David du Colombier authored
Implement an abort note on Plan 9, as an equivalent of the SIGABRT signal on other operating systems. Updates #11975. Change-Id: I010c9b10f2fbd2471aacd1d073368d975a2f0592 Reviewed-on: https://go-review.googlesource.com/16300Reviewed-by:
-
Matthew Dempsky authored
When a new tiny block is allocated because we're allocating an object that won't fit into the current block, mallocgc saves the new block if it has more space leftover than the old block. However, the logic for this was subtly broken in golang.org/cl/2814, resulting in never saving (or consequently reusing) a tiny block. Change-Id: Ib5f6769451fb82877ddeefe75dfe79ed4a04fd40 Reviewed-on: https://go-review.googlesource.com/16330 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
Necessary to ensure that subsequent tools can continue to find then end of the export data section simply by searching for "$$". Adjusted gcimporter used by go/types accordingly. Also, fixed a bug in gcimporter related to reading export data in debug format. Change-Id: Iaea4ed05edd8a5bab28ebe5b19a4740f5e537d35 Reviewed-on: https://go-review.googlesource.com/16283Reviewed-by:
Chris Manghane <cmang@golang.org>
-
Austin Clements authored
Currently data and BSS root marking are each a single markroot job. This makes them difficult to load balance, which can draw out mark termination time if they are large. Fix this by splitting both in to 256K chunks. While we're putting in the infrastructure for dynamic roots, we also replace the fixed sharding of the span roots with sharding in to fixed sizes. In addition to helping balance root marking, this also paves the way to parallelizing concurrent scan and to letting assists help with root marking. Updates #10345. This fixes the data and BSS aspects of that bug; it does not partition scanning of large heap objects. This has negligible effect on either the go1 benchmarks or the garbage benchmark: name old time/op new time/op delta XBenchGarbage-12 4.90ms ± 1% 4.91ms ± 2% ~ (p=0.058 n=17+16) name old time/op new time/op delta BinaryTree17-12 3.11s ± 4% 3.12s ± 4% ~ (p=0.512 n=20+20) Fannkuch11-12 2.53s ± 2% 2.47s ± 2% -2.28% (p=0.000 n=20+18) FmtFprintfEmpty-12 49.1ns ± 1% 50.0ns ± 4% +1.68% (p=0.008 n=18+20) FmtFprintfString-12 170ns ± 0% 172ns ± 1% +1.05% (p=0.000 n=14+19) FmtFprintfInt-12 174ns ± 1% 162ns ± 1% -6.81% (p=0.000 n=18+17) FmtFprintfIntInt-12 284ns ± 1% 277ns ± 1% -2.42% (p=0.000 n=20+19) FmtFprintfPrefixedInt-12 252ns ± 1% 244ns ± 1% -2.84% (p=0.000 n=18+20) FmtFprintfFloat-12 317ns ± 0% 311ns ± 0% -1.95% (p=0.000 n=19+18) FmtManyArgs-12 1.08µs ± 1% 1.11µs ± 1% +3.43% (p=0.000 n=18+19) GobDecode-12 8.56ms ± 1% 8.61ms ± 1% +0.50% (p=0.020 n=20+20) GobEncode-12 6.58ms ± 1% 6.57ms ± 1% ~ (p=0.792 n=20+19) Gzip-12 317ms ± 3% 317ms ± 2% ~ (p=0.840 n=19+19) Gunzip-12 41.6ms ± 0% 41.6ms ± 0% +0.07% (p=0.027 n=18+15) HTTPClientServer-12 62.2µs ± 1% 62.3µs ± 1% ~ (p=0.283 n=19+20) JSONEncode-12 16.5ms ± 2% 16.5ms ± 1% ~ (p=0.857 n=20+19) JSONDecode-12 58.5ms ± 1% 61.3ms ± 1% +4.67% (p=0.000 n=18+17) Mandelbrot200-12 3.84ms ± 0% 3.84ms ± 0% ~ (p=0.259 n=17+17) GoParse-12 3.70ms ± 2% 3.74ms ± 2% +0.96% (p=0.009 n=19+20) RegexpMatchEasy0_32-12 100ns ± 1% 100ns ± 0% +0.31% (p=0.040 n=19+15) RegexpMatchEasy0_1K-12 340ns ± 1% 340ns ± 1% ~ (p=0.411 n=17+19) RegexpMatchEasy1_32-12 82.7ns ± 2% 82.3ns ± 1% ~ (p=0.456 n=20+19) RegexpMatchEasy1_1K-12 498ns ± 2% 495ns ± 0% ~ (p=0.108 n=19+17) RegexpMatchMedium_32-12 130ns ± 1% 130ns ± 2% ~ (p=0.405 n=18+19) RegexpMatchMedium_1K-12 39.4µs ± 2% 39.1µs ± 1% -0.64% (p=0.002 n=20+19) RegexpMatchHard_32-12 2.03µs ± 2% 2.02µs ± 0% ~ (p=0.561 n=20+17) RegexpMatchHard_1K-12 61.1µs ± 2% 60.8µs ± 1% ~ (p=0.615 n=19+18) Revcomp-12 532ms ± 2% 531ms ± 1% ~ (p=0.470 n=19+19) Template-12 68.5ms ± 1% 69.1ms ± 1% +0.87% (p=0.000 n=17+17) TimeParse-12 344ns ± 2% 344ns ± 1% +0.25% (p=0.032 n=19+18) TimeFormat-12 347ns ± 1% 362ns ± 1% +4.27% (p=0.000 n=17+19) [Geo mean] 62.3µs 62.3µs -0.04% name old speed new speed delta GobDecode-12 89.6MB/s ± 1% 89.2MB/s ± 1% -0.50% (p=0.019 n=20+20) GobEncode-12 117MB/s ± 1% 117MB/s ± 1% ~ (p=0.797 n=20+19) Gzip-12 61.3MB/s ± 3% 61.2MB/s ± 2% ~ (p=0.834 n=19+19) Gunzip-12 467MB/s ± 0% 466MB/s ± 0% -0.07% (p=0.027 n=18+15) JSONEncode-12 117MB/s ± 2% 117MB/s ± 1% ~ (p=0.851 n=20+19) JSONDecode-12 33.2MB/s ± 1% 31.7MB/s ± 1% -4.47% (p=0.000 n=18+17) GoParse-12 15.6MB/s ± 2% 15.5MB/s ± 2% -0.95% (p=0.008 n=19+20) RegexpMatchEasy0_32-12 321MB/s ± 2% 320MB/s ± 1% -0.57% (p=0.002 n=17+17) RegexpMatchEasy0_1K-12 3.01GB/s ± 1% 3.01GB/s ± 1% ~ (p=0.132 n=17+18) RegexpMatchEasy1_32-12 387MB/s ± 2% 389MB/s ± 1% ~ (p=0.423 n=20+19) RegexpMatchEasy1_1K-12 2.05GB/s ± 2% 2.06GB/s ± 0% ~ (p=0.129 n=19+17) RegexpMatchMedium_32-12 7.64MB/s ± 1% 7.66MB/s ± 1% ~ (p=0.258 n=18+19) RegexpMatchMedium_1K-12 26.0MB/s ± 2% 26.2MB/s ± 1% +0.64% (p=0.002 n=20+19) RegexpMatchHard_32-12 15.7MB/s ± 2% 15.8MB/s ± 1% ~ (p=0.510 n=20+17) RegexpMatchHard_1K-12 16.8MB/s ± 2% 16.8MB/s ± 1% ~ (p=0.603 n=19+18) Revcomp-12 477MB/s ± 2% 479MB/s ± 1% ~ (p=0.470 n=19+19) Template-12 28.3MB/s ± 1% 28.1MB/s ± 1% -0.85% (p=0.000 n=17+17) [Geo mean] 100MB/s 100MB/s -0.26% Change-Id: Ib0bfe0145675ce88c5a8791752f7486ac98805b4 Reviewed-on: https://go-review.googlesource.com/16043Reviewed-by:
Rick Hudson <rlh@golang.org>
-
David Crawshaw authored
It's the only ARM version we have ever supported on android. (Not setting it caused some builder timeouts.) Change-Id: I26061434252ff2a236bb31d95787a1c582d24b3f Reviewed-on: https://go-review.googlesource.com/16295Reviewed-by:
Hyang-Ah Hana Kim <hyangah@gmail.com>
-
David Crawshaw authored
I went looking for an arm system whose stacks are by default smaller than 64KB. In fact the smallest common linux target I could find was Android, which like iOS uses 1MB stacks. Fixes #11873 Change-Id: Ieeb66ad095b3da18d47ba21360ea75152a4107c6 Reviewed-on: https://go-review.googlesource.com/14602Reviewed-by:
Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by:
Minux Ma <minux@golang.org>
-
Marcel van Lohuizen authored
gc will need to be rebuild. Package that assume f.PkgPath != nil means a field is unexported and must be ignored must be revised to check for f.PkgPath != nil && !f.Anonymous, so that they do try to walk into the embedded fields to look for exported fields contained within. Closes #12367, fixes #7363, fixes #11007, and fixes #7247. Change-Id: I16402ee21ccfede80f277f84b3995cf26e97433d Reviewed-on: https://go-review.googlesource.com/14085Reviewed-by:
Russ Cox <rsc@golang.org>
-
Marcel van Lohuizen authored
Addresses issue #12367. Must be checked in before CL 14010. Change-Id: I4523a1de112ed02371504e27882659bce8028a9f Reviewed-on: https://go-review.googlesource.com/14012Reviewed-by:
-
Marcel van Lohuizen authored
Addresses issue #12367. Must be checked in before CL 14010. Change-Id: I7233c3a62d4f55d0ac7e8a87df5fc4ee7beb7207 Reviewed-on: https://go-review.googlesource.com/14011Reviewed-by:
-
Marcel van Lohuizen authored
Cover some functions that weren't benched before and add InString variants if the underlying implementation is different. Note: compare (Valid|RuneCount)InString* to their (Valid|RuneCount)* counterparts. It shows, somewhat unexpectedly, that ranging over a string is *much* slower than using calls to DecodeRune. Results: In order to avoid a discrepancy in measuring the performance of core we could leave the names of the string-based measurements unchanged and suffix the added alternatives with Bytes. Compared to old: BenchmarkRuneCountTenASCIIChars-8 44.3 12.4 -72.01% BenchmarkRuneCountTenJapaneseChars-8 167 67.1 -59.82% BenchmarkEncodeASCIIRune-8 3.37 3.44 +2.08% BenchmarkEncodeJapaneseRune-8 7.19 7.24 +0.70% BenchmarkDecodeASCIIRune-8 5.41 5.53 +2.22% BenchmarkDecodeJapaneseRune-8 8.17 8.41 +2.94% All benchmarks: BenchmarkRuneCountTenASCIIChars-8 100000000 12.4 ns/op BenchmarkRuneCountTenJapaneseChars-8 20000000 67.1 ns/op BenchmarkRuneCountInStringTenASCIIChars-8 30000000 44.5 ns/op BenchmarkRuneCountInStringTenJapaneseChars-8 10000000 165 ns/op BenchmarkValidTenASCIIChars-8 100000000 12.5 ns/op BenchmarkValidTenJapaneseChars-8 20000000 71.1 ns/op BenchmarkValidStringTenASCIIChars-8 30000000 50.0 ns/op BenchmarkValidStringTenJapaneseChars-8 10000000 161 ns/op BenchmarkEncodeASCIIRune-8 500000000 3.44 ns/op BenchmarkEncodeJapaneseRune-8 200000000 7.24 ns/op BenchmarkDecodeASCIIRune-8 300000000 5.53 ns/op BenchmarkDecodeJapaneseRune-8 200000000 8.41 ns/op BenchmarkFullASCIIRune-8 500000000 3.91 ns/op BenchmarkFullJapaneseRune-8 300000000 4.22 ns/op Change-Id: I674d2ee4917b975a37717bbfa1082cc84dcd275e Reviewed-on: https://go-review.googlesource.com/14431Reviewed-by:
-
Marcel van Lohuizen authored
This CL changes reflect to allow access to exported fields and methods in unexported embedded structs for gccgo and after gc has been adjusted to disallow access to embedded unexported structs. Adresses #12367, #7363, #11007, and #7247. Change-Id: If80536eab35abcd25300d8ddc2d27d5c42d7e78e Reviewed-on: https://go-review.googlesource.com/14010Reviewed-by:
-
- 23 Oct, 2015 13 commits
-
-
Caleb Spare authored
This copies the change from CL 16158 (applied as 22d4c8bf). Updates #13013 Change-Id: Id7d02e63d92806f06a4e064a91b2fb6574fe385f Reviewed-on: https://go-review.googlesource.com/16291Reviewed-by:
-
Shenghou Ma authored
Fixes #12427. Change-Id: I46725620c1e163f3b60ffcd85e5388fa646f074d Reviewed-on: https://go-review.googlesource.com/15997Reviewed-by:
-
Shenghou Ma authored
Fixes #12862. Change-Id: I6921ae31bd5515f344fd97d08eafc317228b98a0 Reviewed-on: https://go-review.googlesource.com/15590Reviewed-by:
-
Håvard Haugen authored
Passes go build -a -toolexec 'toolstash -cmp' std cmd. Change-Id: Ib3d2c50601546495e7f1ab153d2978b1e3774101 Reviewed-on: https://go-review.googlesource.com/14800 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
David Crawshaw authored
Depends on external linking right now. I have no immediate use for this, but wanted to check how hard it is to support as android/amd64 is coming and it will require PIE. Change-Id: I65c6b19159f40db4c79cf312cd0368c2b2527bfd Reviewed-on: https://go-review.googlesource.com/16072Reviewed-by:
-
Caleb Spare authored
Fixes #13013 Change-Id: I6cf500eacdce76e303fc1cd92dd1c80eef0986bc Reviewed-on: https://go-review.googlesource.com/16158Reviewed-by:
-
Matthew Dempsky authored
Change-Id: I27589395f547c5837dc7536a0ab5bc7cc23a4ff6 Reviewed-on: https://go-review.googlesource.com/10872 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
David Crawshaw authored
Change-Id: If30cf9c94b58e18564db46c15c6f5cc14ec1a6fa Reviewed-on: https://go-review.googlesource.com/16271Reviewed-by:
-
Jeremy Jackins authored
Update old c-style comments to look like Go comments. Also replace some lingering references to old .c files that don't exist anymore. Change-Id: I72b2407a40fc76c23e9048643e0622fd70b4cf90 Reviewed-on: https://go-review.googlesource.com/16190 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
-
Alex Brainman authored
Fixes #11671 Change-Id: Ide1f8d92637dad2a2faed391329f9b6001789b76 Reviewed-on: https://go-review.googlesource.com/14742Reviewed-by:
-
Nathan VanBenschoten authored
Change-Id: I0f494c9f17cb6bb0cf5e7214cf033fdbd48f27f7 Reviewed-on: https://go-review.googlesource.com/16240Reviewed-by:
-
Didier Spezia authored
Regular expressions involving a (x){0} term are simplified by removing this term from the expression, just before the expression is compiled. The number of subexpressions is evaluated before the simplification. The number of capture instructions in the compiled expressions is not necessarily in line with the number of subexpressions. When the ReplaceAll(String) methods are used, a number of capture slots (nmatch) is evaluated as 2*(s+1) (s being the number of subexpressions). In some case, it can be higher than the number of capture instructions evaluated at compile time, resulting in a panic when the internal slices of regexp.machine are resized to this value. Fixed by capping the number of capture slots to the number of capture instructions. I must say I do not really see the benefits of setting nmatch lower than re.prog.NumCap using this 2*(s+1) formula, so perhaps this can be further simplified. Fixes #11178 Fixes #11176 Change-Id: I21415e8ef2dd5f2721218e9a679f7f6bfb76ae9b Reviewed-on: https://go-review.googlesource.com/14013Reviewed-by: -
Gaurish Sharma authored
These methods didn't had any examples, so added them. Examples makes things more clear diff --git a/src/strings/example_test.go b/src/strings/example_test.go index 7243e16..b7763bb 100644 --- a/src/strings/example_test.go +++ b/src/strings/example_test.go @@ -223,3 +223,19 @@ func ExampleTrimPrefix() { fmt.Print("Hello" + s) // Output: Hello, world! } + +func ExampleHasPrefix() { + fmt.Println(strings.HasPrefix("hello", "hell")) + fmt.Println(strings.HasPrefix("hello", "heaven")) + // Output: + // true + // false +} + +func ExampleHasSuffix() { + fmt.Println(strings.HasSuffix("hello", "llo")) + fmt.Println(strings.HasSuffix("hello", "hell")) + // Output: + // true + // false +} Change-Id: I5d451c669bd05e19a2afc33ed2ec59b280c2c2d9 Reviewed-on: https://go-review.googlesource.com/12065Reviewed-by:
-
- 22 Oct, 2015 1 commit
-
-
Robert Griesemer authored
Per the latest spec change, Go doesn't have -0 constants. Change-Id: Ic2bcdc3bf507d121ed204f30f6744bb8764202c0 Reviewed-on: https://go-review.googlesource.com/16232Reviewed-by:
-
