- 28 Apr, 2015 6 commits
-
-
Russ Cox authored
This should obviously have no performance impact. Listing numbers just as a sanity check for the benchmark comparison program: it should (and does) find nothing to report. name old new delta BenchmarkBinaryTree17 18.0s × (0.99,1.01) 17.9s × (0.99,1.00) ~ BenchmarkFannkuch11 4.36s × (1.00,1.00) 4.35s × (1.00,1.00) ~ BenchmarkFmtFprintfEmpty 120ns × (0.99,1.06) 120ns × (0.94,1.05) ~ BenchmarkFmtFprintfString 480ns × (0.99,1.01) 477ns × (1.00,1.00) ~ BenchmarkFmtFprintfInt 451ns × (0.99,1.01) 450ns × (0.99,1.01) ~ BenchmarkFmtFprintfIntInt 766ns × (0.99,1.01) 765ns × (0.99,1.01) ~ BenchmarkFmtFprintfPrefixedInt 569ns × (0.99,1.01) 569ns × (0.99,1.01) ~ BenchmarkFmtFprintfFloat 728ns × (1.00,1.01) 728ns × (1.00,1.00) ~ BenchmarkFmtManyArgs 2.81µs × (1.00,1.01) 2.82µs × (0.99,1.01) ~ BenchmarkGobDecode 39.4ms × (0.99,1.01) 39.1ms × (0.99,1.01) ~ BenchmarkGobEncode 39.4ms × (0.99,1.00) 39.4ms × (0.99,1.01) ~ BenchmarkGzip 660ms × (1.00,1.01) 661ms × (0.99,1.01) ~ BenchmarkGunzip 143ms × (1.00,1.00) 143ms × (1.00,1.00) ~ BenchmarkHTTPClientServer 132µs × (0.99,1.01) 133µs × (0.99,1.01) ~ BenchmarkJSONEncode 57.1ms × (0.99,1.01) 57.3ms × (0.99,1.04) ~ BenchmarkJSONDecode 138ms × (1.00,1.01) 139ms × (0.99,1.00) ~ BenchmarkMandelbrot200 6.02ms × (1.00,1.00) 6.02ms × (1.00,1.00) ~ BenchmarkGoParse 9.79ms × (0.92,1.07) 9.72ms × (0.92,1.11) ~ BenchmarkRegexpMatchEasy0_32 210ns × (1.00,1.01) 209ns × (1.00,1.01) ~ BenchmarkRegexpMatchEasy0_1K 593ns × (0.99,1.01) 592ns × (0.99,1.00) ~ BenchmarkRegexpMatchEasy1_32 182ns × (0.99,1.01) 183ns × (0.98,1.01) ~ BenchmarkRegexpMatchEasy1_1K 1.01µs × (1.00,1.01) 1.01µs × (1.00,1.01) ~ BenchmarkRegexpMatchMedium_32 331ns × (1.00,1.00) 330ns × (1.00,1.00) ~ BenchmarkRegexpMatchMedium_1K 92.6µs × (1.00,1.01) 92.4µs × (1.00,1.00) ~ BenchmarkRegexpMatchHard_32 4.58µs × (0.99,1.05) 4.77µs × (0.95,1.01) ~ BenchmarkRegexpMatchHard_1K 136µs × (1.00,1.01) 136µs × (1.00,1.00) ~ BenchmarkRevcomp 900ms × (0.99,1.06) 906ms × (0.99,1.05) ~ BenchmarkTemplate 171ms × (1.00,1.01) 171ms × (0.99,1.01) ~ BenchmarkTimeParse 637ns × (1.00,1.00) 638ns × (1.00,1.00) ~ BenchmarkTimeFormat 742ns × (1.00,1.00) 745ns × (0.99,1.02) ~ Change-Id: I59ec875715cb176bbffa709546370a6a7fc5a75d Reviewed-on: https://go-review.googlesource.com/9309Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
Minor code generation optimization I've been meaning to do for a while and noticed while working on the emitted write barrier code. Using MOV lets the compiler and maybe the processor do copy propagation. name old new delta BenchmarkBinaryTree17 17.9s × (0.99,1.01) 18.0s × (0.99,1.01) ~ BenchmarkFannkuch11 4.42s × (1.00,1.00) 4.36s × (1.00,1.00) -1.39% BenchmarkFmtFprintfEmpty 118ns × (0.96,1.02) 120ns × (0.99,1.06) ~ BenchmarkFmtFprintfString 486ns × (0.99,1.01) 480ns × (0.99,1.01) -1.34% BenchmarkFmtFprintfInt 457ns × (0.99,1.01) 451ns × (0.99,1.01) -1.31% BenchmarkFmtFprintfIntInt 768ns × (1.00,1.01) 766ns × (0.99,1.01) ~ BenchmarkFmtFprintfPrefixedInt 584ns × (0.99,1.03) 569ns × (0.99,1.01) -2.57% BenchmarkFmtFprintfFloat 739ns × (0.99,1.00) 728ns × (1.00,1.01) -1.49% BenchmarkFmtManyArgs 2.77µs × (1.00,1.00) 2.81µs × (1.00,1.01) +1.53% BenchmarkGobDecode 39.3ms × (0.99,1.01) 39.4ms × (0.99,1.01) ~ BenchmarkGobEncode 39.4ms × (0.99,1.00) 39.4ms × (0.99,1.00) ~ BenchmarkGzip 661ms × (0.99,1.01) 660ms × (1.00,1.01) ~ BenchmarkGunzip 142ms × (1.00,1.00) 143ms × (1.00,1.00) +0.20% BenchmarkHTTPClientServer 133µs × (0.98,1.01) 132µs × (0.99,1.01) ~ BenchmarkJSONEncode 56.5ms × (0.99,1.01) 57.1ms × (0.99,1.01) +0.94% BenchmarkJSONDecode 143ms × (1.00,1.00) 138ms × (1.00,1.01) -3.22% BenchmarkMandelbrot200 6.01ms × (1.00,1.00) 6.02ms × (1.00,1.00) ~ BenchmarkGoParse 9.63ms × (0.94,1.07) 9.79ms × (0.92,1.07) ~ BenchmarkRegexpMatchEasy0_32 210ns × (1.00,1.00) 210ns × (1.00,1.01) ~ BenchmarkRegexpMatchEasy0_1K 596ns × (0.99,1.01) 593ns × (0.99,1.01) ~ BenchmarkRegexpMatchEasy1_32 184ns × (0.99,1.01) 182ns × (0.99,1.01) ~ BenchmarkRegexpMatchEasy1_1K 1.01µs × (0.99,1.01) 1.01µs × (1.00,1.01) ~ BenchmarkRegexpMatchMedium_32 327ns × (1.00,1.01) 331ns × (1.00,1.00) +1.22% BenchmarkRegexpMatchMedium_1K 93.0µs × (1.00,1.02) 92.6µs × (1.00,1.01) ~ BenchmarkRegexpMatchHard_32 4.76µs × (0.95,1.01) 4.58µs × (0.99,1.05) ~ BenchmarkRegexpMatchHard_1K 136µs × (1.00,1.01) 136µs × (1.00,1.01) ~ BenchmarkRevcomp 892ms × (1.00,1.01) 900ms × (0.99,1.06) ~ BenchmarkTemplate 175ms × (0.99,1.00) 171ms × (1.00,1.01) -2.36% BenchmarkTimeParse 638ns × (1.00,1.00) 637ns × (1.00,1.00) ~ BenchmarkTimeFormat 772ns × (1.00,1.00) 742ns × (1.00,1.00) -3.95% Change-Id: I6504e310cb9cf48a73d539c478b4dbcacde208b2 Reviewed-on: https://go-review.googlesource.com/9308Reviewed-by:
-
Russ Cox authored
This is primarily preparation for inlining, not an optimization by itself, but it still helps some. name old new delta BenchmarkBinaryTree17 18.2s × (0.99,1.01) 17.9s × (0.99,1.01) -1.57% BenchmarkFannkuch11 4.44s × (1.00,1.00) 4.42s × (1.00,1.00) -0.40% BenchmarkFmtFprintfEmpty 119ns × (0.95,1.02) 118ns × (0.96,1.02) ~ BenchmarkFmtFprintfString 501ns × (0.99,1.02) 486ns × (0.99,1.01) -2.89% BenchmarkFmtFprintfInt 474ns × (0.99,1.00) 457ns × (0.99,1.01) -3.59% BenchmarkFmtFprintfIntInt 792ns × (1.00,1.00) 768ns × (1.00,1.01) -3.03% BenchmarkFmtFprintfPrefixedInt 574ns × (1.00,1.01) 584ns × (0.99,1.03) +1.83% BenchmarkFmtFprintfFloat 749ns × (1.00,1.00) 739ns × (0.99,1.00) -1.34% BenchmarkFmtManyArgs 2.94µs × (1.00,1.01) 2.77µs × (1.00,1.00) -5.76% BenchmarkGobDecode 39.5ms × (0.99,1.01) 39.3ms × (0.99,1.01) ~ BenchmarkGobEncode 39.4ms × (1.00,1.01) 39.4ms × (0.99,1.00) ~ BenchmarkGzip 658ms × (1.00,1.01) 661ms × (0.99,1.01) ~ BenchmarkGunzip 142ms × (1.00,1.00) 142ms × (1.00,1.00) +0.22% BenchmarkHTTPClientServer 134µs × (0.99,1.01) 133µs × (0.98,1.01) ~ BenchmarkJSONEncode 57.1ms × (0.99,1.01) 56.5ms × (0.99,1.01) ~ BenchmarkJSONDecode 141ms × (1.00,1.00) 143ms × (1.00,1.00) +1.09% BenchmarkMandelbrot200 6.01ms × (1.00,1.00) 6.01ms × (1.00,1.00) ~ BenchmarkGoParse 10.1ms × (0.91,1.09) 9.6ms × (0.94,1.07) ~ BenchmarkRegexpMatchEasy0_32 207ns × (1.00,1.01) 210ns × (1.00,1.00) +1.45% BenchmarkRegexpMatchEasy0_1K 592ns × (0.99,1.00) 596ns × (0.99,1.01) +0.68% BenchmarkRegexpMatchEasy1_32 184ns × (0.99,1.01) 184ns × (0.99,1.01) ~ BenchmarkRegexpMatchEasy1_1K 1.01µs × (1.00,1.00) 1.01µs × (0.99,1.01) ~ BenchmarkRegexpMatchMedium_32 327ns × (0.99,1.00) 327ns × (1.00,1.01) ~ BenchmarkRegexpMatchMedium_1K 92.5µs × (1.00,1.00) 93.0µs × (1.00,1.02) +0.48% BenchmarkRegexpMatchHard_32 4.79µs × (0.95,1.00) 4.76µs × (0.95,1.01) ~ BenchmarkRegexpMatchHard_1K 136µs × (1.00,1.00) 136µs × (1.00,1.01) ~ BenchmarkRevcomp 900ms × (0.99,1.01) 892ms × (1.00,1.01) ~ BenchmarkTemplate 170ms × (0.99,1.01) 175ms × (0.99,1.00) +2.95% BenchmarkTimeParse 645ns × (1.00,1.00) 638ns × (1.00,1.00) -1.16% BenchmarkTimeFormat 740ns × (1.00,1.00) 772ns × (1.00,1.00) +4.39% Change-Id: I0be905e32791e0cb70ff01f169c4b309a971d981 Reviewed-on: https://go-review.googlesource.com/9159Reviewed-by:
Rick Hudson <rlh@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
Clean up after CL 5310. Change-Id: Ib870e7b9d26eb118eefdaa3e76dcec4a4d459584 Reviewed-on: https://go-review.googlesource.com/9398Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Josh Bleecher Snyder authored
With this fix, GOMAXPROCS=8 ./all.bash passes, at least on my machine. Fixes #10216. Change-Id: Ib5991950892a1399ec81aced0a52b435e6f83fdf Reviewed-on: https://go-review.googlesource.com/9392Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Mikio Hara authored
Change-Id: I9fa678e43b4ae3970323cac474b5f86d4d933997 Reviewed-on: https://go-review.googlesource.com/9382Reviewed-by:
-
- 27 Apr, 2015 24 commits
-
-
Matthew Dempsky authored
These were fixed a little while ago, but overlooked when reenabling disabled tests. Update #9968. Change-Id: I301ef587e580c517a170ad08ff897118b58cedec Reviewed-on: https://go-review.googlesource.com/9347 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Rob Pike authored
Change-Id: I883017b67e8fa76b6f123e8f9bcec3d6f820bbb3 Reviewed-on: https://go-review.googlesource.com/9348Reviewed-by:
Rob Pike <r@golang.org>
-
Rob Pike authored
Add the new go doc command to the go command, installed in the tool directory. (Still to do: tests) Fix cmd/dist to remove old "package documentation" code that was stopping it from including cmd/go/doc.go in the build. Implement the doc command. Here is the help info from "go help doc": === usage: go doc [-u] [package|[package.]symbol[.method]] Doc accepts at most one argument, indicating either a package, a symbol within a package, or a method of a symbol. go doc go doc <pkg> go doc <sym>[.<method>] go doc [<pkg>].<sym>[.<method>] Doc interprets the argument to see what it represents, determined by its syntax and which packages and symbols are present in the source directories of GOROOT and GOPATH. The first item in this list that succeeds is the one whose documentation is printed. For packages, the order of scanning is determined by the file system, however the GOROOT tree is always scanned before GOPATH. If there is no package specified or matched, the package in the current directory is selected, so "go doc" shows the documentation for the current package and "go doc Foo" shows the documentation for symbol Foo in the current package. Doc prints the documentation comments associated with the top-level item the argument identifies (package, type, method) followed by a one-line summary of each of the first-level items "under" that item (package-level declarations for a package, methods for a type, etc.) The package paths must be either a qualified path or a proper suffix of a path (see examples below). The go tool's usual package mechanism does not apply: package path elements like . and ... are not implemented by go doc. When matching symbols, lower-case letters match either case but upper-case letters match exactly. Examples: go doc Show documentation for current package. go doc Foo Show documentation for Foo in the current package. (Foo starts with a capital letter so it cannot match a package path.) go doc json Show documentation for the encoding/json package. go doc json Shorthand for encoding/json assuming only one json package is present in the tree. go doc json.Number (or go doc json.number) Show documentation and method summary for json.Number. go doc json.Number.Int64 (or go doc json.number.int64) Show documentation for the Int64 method of json.Number. Flags: -u Show documentation for unexported as well as exported symbols and methods. === Still to do: Tests. Disambiguation when there is both foo and Foo. Flag for case-sensitive matching. Change-Id: I83d409a68688a5445f54297a7e7c745f749b9e66 Reviewed-on: https://go-review.googlesource.com/9227Reviewed-by:
Russ Cox <rsc@golang.org>
-
Austin Clements authored
Some race tests were sensitive to the goroutine scheduling order. When this changed in commit e870f06c, these tests started to fail. Fix TestRaceHeapParam by ensuring that the racing goroutine has run before the test exits. Fix TestRaceRWMutexMultipleReaders by adding a third reader to ensure that two readers wind up on the same side of the writer (and race with each other) regardless of the schedule. Fix TestRaceRange by ensuring that the racing goroutine runs before the main goroutine exits the loop it races with. Change-Id: Iaf002f8730ea42227feaf2f3c51b9a1e57ccffdd Reviewed-on: https://go-review.googlesource.com/9402Reviewed-by:
-
Russ Cox authored
This makes the OS X firewall box pop up. Not run during all.bash so hasn't been noticed before. Change-Id: I78feb4fd3e1d3c983ae3419085048831c04de3da Reviewed-on: https://go-review.googlesource.com/9401Reviewed-by:
-
Austin Clements authored
ReadMemStats accounts for stacks slightly differently than the runtime does internally. Internally, only stacks allocated by newosproc0 are accounted in memstats.stacks_sys and other stacks are accounted in heap_sys. readmemstats_m shuffles the statistics so all stacks are accounted in StackSys rather than HeapSys. However, currently, readmemstats_m assumes StackSys will be zero when it does this shuffle. This was true until commit 6ad33be2. If it isn't (e.g., if something called newosproc0), StackSys+HeapSys will be different before and after this shuffle, and the Sys sum that was computed earlier will no longer agree with the sum of its components. Fix this by making the shuffle in readmemstats_m not assume that StackSys is zero. Fixes #10585. Change-Id: If13991c8de68bd7b85e1b613d3f12b4fd6fd5813 Reviewed-on: https://go-review.googlesource.com/9366Reviewed-by:
-
David Crawshaw authored
I introduced this build failure in golang.org/cl/9302 but failed to notice due to the other failures on the dashboard. Change-Id: I84bf00f664ba572c1ca722e0136d8a2cf21613ca Reviewed-on: https://go-review.googlesource.com/9363Reviewed-by:
Minux Ma <minux@golang.org>
-
Josh Bleecher Snyder authored
Also call runtime.GC before exit to ensure that the profiler picks up all allocations. Fixes #10537. Change-Id: Ibfbfc88652ac0ce30a6d1ae392f919df6c1e8126 Reviewed-on: https://go-review.googlesource.com/9261Reviewed-by:
Dave Cheney <dave@cheney.net> Reviewed-by:
-
Austin Clements authored
Currently TestRaceCrawl fails to wg.Done for every wg.Adds if the depth ever reaches 0. This causes the test to deadlock. Under the race detector, this deadlock is not detected, so the test eventually times out. This only recently became a problem. Prior to commit e870f06c the depth would never reach 0 because the strict round-robin goroutine schedule ensured that all of the URLs were already "seen" by depth 2. Now that the runtime prefers scheduling the most recently started goroutine, the test is able to reach depth 0 and trigger this deadlock. Change-Id: I5176302a89614a344c84d587073b364833af6590 Reviewed-on: https://go-review.googlesource.com/9344 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
Dmitry Savintsev authored
Replaced code.google.com/p/re2/ with github.com/google/re2/ and updated the file names (re2-exhaustive.txt.bz2 not re2.txt.gz) as well as the re2 make command (make log). Change-Id: I15937b0b8a898d78d45366857ed86421c8d69960 Reviewed-on: https://go-review.googlesource.com/9372Reviewed-by:
-
Russ Cox authored
The master goroutine was returning before the child goroutine had done its final i < b.N (the one that fails and causes it to exit the loop) and then the benchmark harness was updating b.N, causing a read+write race on b.N. Change-Id: I2504270a0de30544736f6c32161337a25b505c3e Reviewed-on: https://go-review.googlesource.com/9368Reviewed-by:
-
Austin Clements authored
Change-Id: I061057414c722c5a0f03c709528afc8554114db6 Reviewed-on: https://go-review.googlesource.com/9367Reviewed-by:
-
Josh Bleecher Snyder authored
This is a follow-up to CL 9269, as suggested by dvyukov. There is probably even more that can be done to speed up this shuffle. It will matter more once CL 7570 (fine-grained locking in select) is in and can be revisited then, with benchmarks. Change-Id: Ic13a27d11cedd1e1f007951214b3bb56b1644f02 Reviewed-on: https://go-review.googlesource.com/9393Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Austin Clements authored
This avoids confusion with the main findrunnable in the scheduler. Change-Id: I8cf40657557a8610a2fe5a2f74598518256ca7f0 Reviewed-on: https://go-review.googlesource.com/9305Reviewed-by:
-
Austin Clements authored
Currently, we use a full stop-the-world around enabling write barriers. This is to ensure that all Gs have enabled write barriers before any blackening occurs (either in gcBgMarkWorker() or in gcAssistAlloc()). However, there's no need to bring the whole world to a synchronous stop to ensure this. This change replaces the STW with a ragged barrier that ensures each P has individually observed that write barriers should be enabled before GC performs any blackening. Change-Id: If2f129a6a55bd8bdd4308067af2b739f3fb41955 Reviewed-on: https://go-review.googlesource.com/8207Reviewed-by:
-
Austin Clements authored
This adds forEachP, which performs a general-purpose ragged global barrier. forEachP takes a callback and invokes it for every P at a GC safe point. Ps that are idle or in a syscall are considered to be at a continuous safe point. forEachP ensures that these Ps do not change state by forcing all syscall Ps into idle and holding the sched.lock. To ensure that Ps do not enter syscall or idle without running the safe-point function, this adds checks for a pending callback every place there is currently a gcwaiting check. We'll use forEachP to replace the STW around enabling the write barrier and to replace the current asynchronous per-M wbuf cache with a cooperatively managed per-P gcWork cache. Change-Id: Ie944f8ce1fead7c79bf271d2f42fcd61a41bb3cc Reviewed-on: https://go-review.googlesource.com/8206Reviewed-by:
-
Josh Bleecher Snyder authored
This reverts commit a9e50a6b. Change-Id: I3c5e459f1030e36bc249910facdae12303a44151 Reviewed-on: https://go-review.googlesource.com/9394Reviewed-by:
-
Josh Bleecher Snyder authored
Instead of running: go test -short runtime -cpu=1 go test -short runtime -cpu=2 go test -short runtime -cpu=4 Run just: go test -short runtime -cpu=1,2,4 This is a return to the Go 1.4.2 behavior. We lose incremental display of progress and per-cpu timing information, but we don't have to recompile and relink the runtime test, which is slow. This cuts about 10s off all.bash. Updates #10571. Change-Id: I6e8c7149780d47439f8bcfa888e6efc84290c60a Reviewed-on: https://go-review.googlesource.com/9350Reviewed-by:
-
Josh Bleecher Snyder authored
Reduces allocs linking cmd/go and runtime.test by ~13%. No functional changes. The most easily addressed sources of allocations after this are expandpkg, rdstring, and symbuf string conversion. These can be reduced by interning strings, but that increases the overall memory footprint. Change-Id: Ifedefc9f2a0403bcc75460d6b139e8408374e058 Reviewed-on: https://go-review.googlesource.com/9391Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Roger Peppe authored
There is no need to escape newlines in char data - it makes the XML larger and harder to read. Change-Id: I1c1fcee1bdffc705c7428f89ca90af8085d6fb73 Reviewed-on: https://go-review.googlesource.com/9310Reviewed-by:
Nigel Tao <nigeltao@golang.org> Reviewed-by:
-
Austin Clements authored
This fixes a bug where the runtime ready()s a goroutine while setting up a new M that's initially marked as spinning, causing the scheduler to later panic when it finds work in the run queue of a P associated with a spinning M. Specifically, the sequence of events that can lead to this is: 1) sysmon calls handoffp to hand off a P stolen from a syscall. 2) handoffp sees no pending work on the P, so it calls startm with spinning set. 3) startm calls newm, which in turn calls allocm to allocate a new M. 4) allocm "borrows" the P we're handing off in order to do allocation and performs this allocation. 5) This allocation may assist the garbage collector, and this assist may detect the end of concurrent mark and ready() the main GC goroutine to signal this. 6) This ready()ing puts the GC goroutine on the run queue of the borrowed P. 7) newm starts the OS thread, which runs mstart and subsequently mstart1, which marks the M spinning because startm was called with spinning set. 8) mstart1 enters the scheduler, which panics because there's work on the run queue, but the M is marked spinning. To fix this, before marking the M spinning in step 7, add a check to see if work was been added to the P's run queue. If this is the case, undo the spinning instead. Fixes #10573. Change-Id: I4670495ae00582144a55ce88c45ae71de597cfa5 Reviewed-on: https://go-review.googlesource.com/9332Reviewed-by:
-
Austin Clements authored
This adds a check that we never put a P on the idle list when it has work on its local run queue. Change-Id: Ifcfab750de60c335148a7f513d4eef17be03b6a7 Reviewed-on: https://go-review.googlesource.com/9324Reviewed-by:
-
Josh Bleecher Snyder authored
This is the optimization made to math/rand in CL 21030043. Change-Id: I231b24fa77cac1fe74ba887db76313b5efaab3e8 Reviewed-on: https://go-review.googlesource.com/9269Reviewed-by:
-
John Dethridge authored
Change-Id: I677a5ee273a4d285a8adff71ffcfeac34afc887f Reviewed-on: https://go-review.googlesource.com/9235Reviewed-by:
-
- 26 Apr, 2015 10 commits
-
-
Adam Langley authored
This change causes the GetCertificate callback to be called if Certificates is empty. Previously this configuration would result in an error. This allows people to have servers that depend entirely on dynamic certificate selection, even when the client doesn't send SNI. Fixes #9208. Change-Id: I2f5a5551215958b88b154c64a114590300dfc461 Reviewed-on: https://go-review.googlesource.com/8792Reviewed-by:
-
Jonathan Rudenberg authored
The OCSP response is currently only exposed via a method on Conn, which makes it inaccessible when using wrappers like net/http. The ConnectionState structure is typically available even when using wrappers and contains many of the other handshake details, so this change exposes the stapled OCSP response in that structure. Change-Id: If8dab49292566912c615d816321b4353e711f71f Reviewed-on: https://go-review.googlesource.com/9361Reviewed-by:
Adam Langley <agl@golang.org> Run-TryBot: Adam Langley <agl@golang.org>
-
David Leon Gil authored
At present, Unmarshal does not check that the point it unmarshals is actually *on* the curve. (It may be on the curve's twist.) This can, as Daniel Bernstein has pointed out at great length, lead to quite devastating attacks. And 3 out of the 4 curves supported by crypto/elliptic have twists with cofactor != 1; P-224, in particular, has a sufficiently large cofactor that it is likely that conventional dlog attacks might be useful. This closes #2445, filed by Watson Ladd. To explain why this was (partially) rejected before being accepted: In the general case, for curves with cofactor != 1, verifying subgroup membership is required. (This is expensive and hard-to-implement.) But, as recent discussion during the CFRG standardization process has brought out, small-subgroup attacks are much less damaging than a twist attack. Change-Id: I284042eb9954ff9b7cde80b8b693b1d468c7e1e8 Reviewed-on: https://go-review.googlesource.com/2421Reviewed-by:
-
Paul van Brouwershaven authored
This implements a method for x509.CertificateRequest to prevent certain attacks and to allow a CA/RA to properly check the validity of the binding between an end entity and a key pair, to prove that it has possession of (i.e., is able to use) the private key corresponding to the public key for which a certificate is requested. RFC 2986 section 3 states: "A certification authority fulfills the request by authenticating the requesting entity and verifying the entity's signature, and, if the request is valid, constructing an X.509 certificate from the distinguished name and public key, the issuer name, and the certification authority's choice of serial number, validity period, and signature algorithm." Change-Id: I37795c3b1dfdfdd455d870e499b63885eb9bda4f Reviewed-on: https://go-review.googlesource.com/7371Reviewed-by:
-
Jonathan Rudenberg authored
This change adds a new method to tls.Config, SetSessionTicketKeys, that changes the key used to encrypt session tickets while the server is running. Additional keys may be provided that will be used to maintain continuity while rotating keys. If a ticket encrypted with an old key is provided by the client, the server will resume the session and provide the client with a ticket encrypted using the new key. Fixes #9994 Change-Id: Idbc16b10ff39616109a51ed39a6fa208faad5b4e Reviewed-on: https://go-review.googlesource.com/9072Reviewed-by:
Jonathan Rudenberg <jonathan@titanous.com> Reviewed-by:
-
Håvard Haugen authored
The command "go tool pprof -top $GOROOT/bin/go /dev/null" now logs that profile is empty instead of panicking. Fixes #9207 Change-Id: I3d55c179277cb19ad52c8f24f1aca85db53ee08d Reviewed-on: https://go-review.googlesource.com/2571 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
-
Jonathan Rudenberg authored
This change adds support for serving and receiving Signed Certificate Timestamps as described in RFC 6962. The server is now capable of serving SCTs listed in the Certificate structure. The client now asks for SCTs and, if any are received, they are exposed in the ConnectionState structure. Fixes #10201 Change-Id: Ib3adae98cb4f173bc85cec04d2bdd3aa0fec70bb Reviewed-on: https://go-review.googlesource.com/8988Reviewed-by:
-
Justin Nuß authored
Currently parseRecord will always start with a nil slice and then resize the slice on append. For input with a fixed number of fields per record we can preallocate the slice to avoid having to resize the slice. This change implements this optimization by using FieldsPerRecord as capacity if it's > 0 and also adds a benchmark to better show the differences. benchmark old ns/op new ns/op delta BenchmarkRead 19741 17909 -9.28% benchmark old allocs new allocs delta BenchmarkRead 59 41 -30.51% benchmark old bytes new bytes delta BenchmarkRead 6276 5844 -6.88% Change-Id: I7c2abc9c80a23571369bcfcc99a8ffc474eae7ab Reviewed-on: https://go-review.googlesource.com/8880Reviewed-by:
-
David Crawshaw authored
Follows the linux signal forwarding semantics from http://golang.org/cl/8712, sharing the implementation of sigfwdgo. Forwarding for 386, arm, and arm64 will follow. Change-Id: I6bf30d563d19da39b6aec6900c7fe12d82ed4f62 Reviewed-on: https://go-review.googlesource.com/9302Reviewed-by:
-
Michael Hudson-Doyle authored
Sorry about this. Fixes #10575 Change-Id: I2de23be68e7d822d182e5a0d6a00c607448d861e Reviewed-on: https://go-review.googlesource.com/9341Reviewed-by:
-
