Commits · 7fbb1b36c37ac49db78042adc7533fb4ab83a4bc · go / golang

01 May, 2015 10 commits

cmd/internal/gc: improve flow of input params to output params · 7fbb1b36

David Chase authored Mar 26, 2015

This includes the following information in the per-function summary:

outK = paramJ   encoded in outK bits for paramJ
outK = *paramJ  encoded in outK bits for paramJ
heap = paramJ   EscHeap
heap = *paramJ  EscContentEscapes

Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.

The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)

A new test was  added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm.  Another new test checks
(some) correctness with array parameters, results, and operations.

The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result.  A test was added against the discovered bug.

The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.

With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.

Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).

Profiling allocations in src/html/template with
for i in {1..5} ;
  do go tool 6g -memprofile=mastx.${i}.prof  -memprofilerate=1 *.go;
  go tool pprof -alloc_objects -text  mastx.${i}.prof ;
done

showed a 15% reduction in allocations performed by the compiler.

Update #3753
Update #4720
Fixes #10466

Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

7fbb1b36

runtime/cgo, cmd/dist: turn off exc_bad_access handler by default · 4044aded

David Crawshaw authored Apr 30, 2015

App Store policy requires programs do not reference the exc_server
symbol. (Some public forum threads show that Unity ran into this
several years ago and it is a hard policy rule.) While some research
suggests that I could write my own version of exc_server, the
expedient course is to disable the exception handler by default.

Go programs only need it when running under lldb, which is primarily
used by tests. So enable the exception handler in cmd/dist when we
are running the tests.

Fixes #10646

Change-Id: I853905254894b5367edb8abd381d45585a78ee8b
Reviewed-on: https://go-review.googlesource.com/9549Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

4044aded

runtime: adjust traceTickDiv for non-x86 architectures · 5f69e739

Shenghou Ma authored Apr 23, 2015

Fixes #10554.
Fixes #10623.

Change-Id: I90fbaa34e3d55c8758178f8d2e7fa41ff1194a1b
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/9247Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Dave Cheney <dave@cheney.net>

5f69e739

cmd/cover: fix build · ffd33449

Dave Cheney authored May 01, 2015

Fix the various builds which don't have a real filesystem or don't support forking.

Change-Id: I3075c662fe6191ecbe70ba359b73d9a88bb06f35
Reviewed-on: https://go-review.googlesource.com/9528Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>

ffd33449

cmd/cover: try once again to fix the build · bc1410a4

Rob Pike authored May 01, 2015

Forgot to update the references to the old cover package. No excuse.

Change-Id: If17b7521f0bf70bc0c8da9c5adf246d90f644637
Reviewed-on: https://go-review.googlesource.com/9564Reviewed-by: Rob Pike <r@golang.org>

bc1410a4

cmd/cover: fix build · e0820ac8

Rob Pike authored May 01, 2015

TBR=rsc

Change-Id: I6ec69013027213c5e7adedd2edb89dea6af876d9
Reviewed-on: https://go-review.googlesource.com/9563Reviewed-by: Rob Pike <r@golang.org>

e0820ac8

cmd/8g: don't call gc.Fatal during initalisation · 443a32e7

Dave Cheney authored May 01, 2015

Fixes #10592

Calling gc.Fatal before gc.Main has been called ends up flushing gc.bstdout before
it is properly set up. Ideally obj.Bflush would handle this case, but that type
and its callers are rather convoluted, so take the simpler route and avoid calling
gc.Fatal altogether.

Change-Id: I338b469e86edba558b6bedff35bb904bfc3d6990
Reviewed-on: https://go-review.googlesource.com/9525Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Run-TryBot: Dave Cheney <dave@cheney.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>

443a32e7

text/template: allow newlines in raw quotes · 04220014

Rob Pike authored Apr 30, 2015

This was disallowed for error-checking reasons but people ask for
it, it's easy, and it's clear what it all means.

Fixes #7323.

Change-Id: I26542f5ac6519e45b335ad789713a4d9e356279b
Reviewed-on: https://go-review.googlesource.com/9537Reviewed-by: Russ Cox <rsc@golang.org>

04220014

doc/go1.5.txt: cover has moved · cf3ac26a

Rob Pike authored May 01, 2015

Change-Id: Ie4b59d72e2b704559e075494e79fdc7b0bca6556
Reviewed-on: https://go-review.googlesource.com/9562Reviewed-by: Rob Pike <r@golang.org>

cf3ac26a

cmd/cover: copy to standard repository from golang.org/x/tools/cmd/cover · 5eddc5ba

Rob Pike authored Apr 30, 2015

This required dealing with the ill-advised split of the profile code
into a separate package. I just copied it over unchanged. The package
does not deserve to be in the standard repository. We can cope
with the duplication.

Also update the go command to know about the new location.

Fixes #10528.

Change-Id: I05170ef3663326d57b9c18888d01163acd9256b6
Reviewed-on: https://go-review.googlesource.com/9560Reviewed-by: Russ Cox <rsc@golang.org>

5eddc5ba

30 Apr, 2015 22 commits

doc/progs: remove flaky timing-sensitive test · 198dceda

Matthew Dempsky authored Apr 30, 2015

Package time already has enough inherently flaky tests covering its
behavior.  No need for more of them.

Fixes #10632.

Change-Id: I1229e9fcc2e28ba2c9b0b79f73638e35dbbe8bbf
Reviewed-on: https://go-review.googlesource.com/9517Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

198dceda

cmd/go: support -buildmode=c-shared for gccgo · 6c0f9c9e

Ian Lance Taylor authored Apr 30, 2015

Change-Id: I4cdfd5a59e0468e9e5400aa06334b21cc80913cd
Reviewed-on: https://go-review.googlesource.com/9550Reviewed-by: David Crawshaw <crawshaw@golang.org>

6c0f9c9e

net/http: document ServeFile and FileServer index.html redirect behavior · 125ed11c

Brad Fitzpatrick authored Apr 30, 2015

Fixes #9876

Change-Id: I97a354fde827dfccc9e373fadea2e37d094439b0
Reviewed-on: https://go-review.googlesource.com/9538Reviewed-by: Rob Pike <r@golang.org>

125ed11c

net: make go DNS use localhost if resolv.conf is missing or empty · f3901357

Alex A Skinner authored Apr 26, 2015

Per resolv.conf man page, "If this file does not exist, only the name
server on the local machine will be queried."

This behavior also occurs if file is present but unreadable,
or if no nameservers are listed.

Fixes #10566

Change-Id: Id5716da0eae534d5ebfafea111bbc657f302e307
Reviewed-on: https://go-review.googlesource.com/9380
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

f3901357

cmd/internal/ld: put the list of packages built into a shared library into an ELF note · 7556948e

Michael Hudson-Doyle authored Apr 29, 2015

Change-Id: I611f7dec2109dc7e2f090ced0a1dca3d4b577134
Reviewed-on: https://go-review.googlesource.com/9520Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

7556948e

misc/cgo/testcshared, misc/cgo/testshared: fix clang warnings and errors · ccaaf1f1

Dave Cheney authored Apr 30, 2015

Fix several warnings generated on the linux-amd64-clang builder
and make it clear to clang that -znow is a linker only flag.

Tested with

    env CC=clang-3.5 ./all.bash
    env CC=gcc-4.8 ./all.bash

Change-Id: I5ca7366ba8bf6221a36d25a2157dda4b4f3e16fa
Reviewed-on: https://go-review.googlesource.com/9523Reviewed-by: Ian Lance Taylor <iant@golang.org>

ccaaf1f1

cmd/go, cmd/cgo: support -buildmode=c-archive for gccgo · 42bb59a3

Ian Lance Taylor authored Apr 29, 2015

This extends the cgo changes in http://golang.org/cl/8094 to gccgo.
It also adds support for setting runtime_iscgo correctly for gccgo;
the gc runtime bases the variable on the runtime/cgo package, but
gccgo has no equivalent to that package.

The go tool supports -buildmode=c-archive for gccgo by linking all the
Go objects together using -r.  For convenience this object is then put
into an archive file.

The go tool now passes -fsplit-stack when building C code for gccgo on
386 and amd64.  This is required for using -r and will also cut down
on unnecessary stack splits.

The go tool no longer applies standard package cgo LDFLAGS when using
gccgo.  This is mainly to avoid getting confused by the LDFLAGS in the
runtime/cgo package that gccgo does not use.

Change-Id: I1d0865b2a362818a033ca9e9e901d0ce250784e7
Reviewed-on: https://go-review.googlesource.com/9511Reviewed-by: David Crawshaw <crawshaw@golang.org>

42bb59a3

html/template: fix quadratic performance with special tags · f4e3e5ea

Didier Spezia authored Apr 29, 2015

The current implementation of the tSpecialTagEnd function
is inefficient since it generates plenty of memory allocations
and converts the whole buffer to lowercase at each call.

If the number of special tags increases linearly with the
template size, the complexity becomes quadratic.

This CL provides an alternative implementation.
While the algorithm is probably still not optimal, it avoids
the quadratic behavior and the memory allocations.

benchmark                          old ns/op     new ns/op     delta
BenchmarkTemplateSpecialTags-4     19326431      532190        -97.25%

benchmark                          old allocs    new allocs    delta
BenchmarkTemplateSpecialTags-4     2650          190           -92.83%

benchmark                          old bytes     new bytes     delta
BenchmarkTemplateSpecialTags-4     4106460       46568         -98.87%

While we are there, make sure we respect the HTML tokenization algorithm.
An end tag needs to be followed by a space, tab, CR, FF, /, or > as described
in https://html.spec.whatwg.org/multipage/syntax.html#tokenization
Explicitly add this check.

Fixes #10605

Change-Id: Ia33ddee164ab608a69ac4183e16ec506bbeaa54c
Reviewed-on: https://go-review.googlesource.com/9502Reviewed-by: Rob Pike <r@golang.org>

f4e3e5ea

runtime: schedule GC work more aggressively · 79a990b8

Russ Cox authored Apr 30, 2015

Schedule the work as early as possible, while still respecting the
utilization percentage on average. The old code tried never to
go above the utilization percentage. The new code is willing
to go above the utilization percentage by one time slice
(but of course after doing that it must wait until the percentage
drops back down to the target before it gets another time slice).

The effect is that for concurrent GCs that can run in a small number
of time slices, the time during which write barriers are enabled is
reduced by one mutator + GC time slice round (possibly 30 ms per GC).

This only affects the fractional GC processor (the remainder of GOMAXPROCS/4),
so it matters most in GOMAXPROCS=1, a bit in GOMAXPROCS=2, and not at
all in GOMAXPROCS=4.

GOMAXPROCS=1
name old mean new mean delta
BenchmarkBinaryTree17 12.4s × (0.98,1.03) 13.5s × (0.97,1.04) +8.84% (p=0.000)
BenchmarkFannkuch11 4.38s × (1.00,1.01) 4.38s × (1.00,1.01) ~ (p=0.343)
BenchmarkFmtFprintfEmpty 88.9ns × (0.97,1.10) 90.1ns × (0.93,1.14) ~ (p=0.224)
BenchmarkFmtFprintfString 356ns × (0.94,1.05) 321ns × (0.94,1.12) -9.77% (p=0.000)
BenchmarkFmtFprintfInt 344ns × (0.98,1.03) 325ns × (0.96,1.03) -5.46% (p=0.000)
BenchmarkFmtFprintfIntInt 622ns × (0.97,1.03) 571ns × (0.95,1.05) -8.09% (p=0.000)
BenchmarkFmtFprintfPrefixedInt 462ns × (0.96,1.04) 431ns × (0.95,1.05) -6.81% (p=0.000)
BenchmarkFmtFprintfFloat 653ns × (0.98,1.03) 621ns × (0.99,1.03) -4.90% (p=0.000)
BenchmarkFmtManyArgs 2.32µs × (0.97,1.03) 2.19µs × (0.98,1.02) -5.43% (p=0.000)
BenchmarkGobDecode 27.0ms × (0.96,1.04) 20.0ms × (0.97,1.04) -26.06% (p=0.000)
BenchmarkGobEncode 26.6ms × (0.99,1.01) 17.8ms × (0.95,1.05) -33.19% (p=0.000)
BenchmarkGzip 659ms × (0.98,1.03) 650ms × (0.99,1.01) -1.34% (p=0.000)
BenchmarkGunzip 145ms × (0.98,1.04) 143ms × (1.00,1.01) -1.47% (p=0.000)
BenchmarkHTTPClientServer 111µs × (0.97,1.04) 110µs × (0.96,1.03) -1.30% (p=0.000)
BenchmarkJSONEncode 52.0ms × (0.97,1.03) 40.8ms × (0.97,1.03) -21.47% (p=0.000)
BenchmarkJSONDecode 127ms × (0.98,1.04) 120ms × (0.98,1.02) -5.55% (p=0.000)
BenchmarkMandelbrot200 6.04ms × (0.99,1.04) 6.02ms × (1.00,1.01) ~ (p=0.176)
BenchmarkGoParse 8.62ms × (0.96,1.08) 8.55ms × (0.93,1.09) ~ (p=0.302)
BenchmarkRegexpMatchEasy0_32 164ns × (0.98,1.05) 165ns × (0.98,1.07) ~ (p=0.293)
BenchmarkRegexpMatchEasy0_1K 546ns × (0.98,1.06) 547ns × (0.97,1.07) ~ (p=0.741)
BenchmarkRegexpMatchEasy1_32 142ns × (0.97,1.09) 141ns × (0.97,1.05) ~ (p=0.231)
BenchmarkRegexpMatchEasy1_1K 904ns × (0.97,1.07) 900ns × (0.98,1.04) ~ (p=0.294)
BenchmarkRegexpMatchMedium_32 256ns × (0.98,1.06) 256ns × (0.97,1.04) ~ (p=0.530)
BenchmarkRegexpMatchMedium_1K 74.2µs × (0.98,1.05) 73.8µs × (0.98,1.04) ~ (p=0.334)
BenchmarkRegexpMatchHard_32 3.94µs × (0.98,1.07) 3.92µs × (0.98,1.05) ~ (p=0.356)
BenchmarkRegexpMatchHard_1K 119µs × (0.98,1.07) 119µs × (0.98,1.06) ~ (p=0.467)
BenchmarkRevcomp 978ms × (0.96,1.09) 984ms × (0.95,1.07) ~ (p=0.448)
BenchmarkTemplate 151ms × (0.96,1.03) 142ms × (0.95,1.04) -5.55% (p=0.000)
BenchmarkTimeParse 628ns × (0.99,1.01) 628ns × (0.99,1.01) ~ (p=0.855)
BenchmarkTimeFormat 729ns × (0.98,1.06) 734ns × (0.97,1.05) ~ (p=0.149)

GOMAXPROCS=2
name old mean new mean delta
BenchmarkBinaryTree17-2 9.80s × (0.97,1.03) 9.85s × (0.99,1.02) ~ (p=0.444)
BenchmarkFannkuch11-2 4.35s × (0.99,1.01) 4.40s × (0.98,1.05) ~ (p=0.099)
BenchmarkFmtFprintfEmpty-2 86.7ns × (0.97,1.05) 85.9ns × (0.98,1.04) ~ (p=0.409)
BenchmarkFmtFprintfString-2 297ns × (0.98,1.01) 297ns × (0.99,1.01) ~ (p=0.743)
BenchmarkFmtFprintfInt-2 309ns × (0.98,1.02) 310ns × (0.99,1.01) ~ (p=0.464)
BenchmarkFmtFprintfIntInt-2 525ns × (0.97,1.05) 518ns × (0.99,1.01) ~ (p=0.151)
BenchmarkFmtFprintfPrefixedInt-2 408ns × (0.98,1.02) 408ns × (0.98,1.03) ~ (p=0.797)
BenchmarkFmtFprintfFloat-2 603ns × (0.99,1.01) 604ns × (0.98,1.02) ~ (p=0.588)
BenchmarkFmtManyArgs-2 2.07µs × (0.98,1.02) 2.05µs × (0.99,1.01) ~ (p=0.091)
BenchmarkGobDecode-2 19.1ms × (0.97,1.01) 19.3ms × (0.97,1.04) ~ (p=0.195)
BenchmarkGobEncode-2 16.2ms × (0.97,1.03) 16.4ms × (0.99,1.01) ~ (p=0.069)
BenchmarkGzip-2 652ms × (0.99,1.01) 651ms × (0.99,1.01) ~ (p=0.705)
BenchmarkGunzip-2 143ms × (1.00,1.01) 143ms × (1.00,1.00) ~ (p=0.665)
BenchmarkHTTPClientServer-2 149µs × (0.92,1.11) 149µs × (0.91,1.08) ~ (p=0.862)
BenchmarkJSONEncode-2 34.6ms × (0.98,1.02) 37.2ms × (0.99,1.01) +7.56% (p=0.000)
BenchmarkJSONDecode-2 117ms × (0.99,1.01) 117ms × (0.99,1.01) ~ (p=0.858)
BenchmarkMandelbrot200-2 6.10ms × (0.99,1.03) 6.03ms × (1.00,1.00) ~ (p=0.083)
BenchmarkGoParse-2 8.25ms × (0.98,1.01) 8.21ms × (0.99,1.02) ~ (p=0.307)
BenchmarkRegexpMatchEasy0_32-2 162ns × (0.99,1.02) 162ns × (0.99,1.01) ~ (p=0.857)
BenchmarkRegexpMatchEasy0_1K-2 541ns × (0.99,1.01) 540ns × (1.00,1.00) ~ (p=0.530)
BenchmarkRegexpMatchEasy1_32-2 138ns × (1.00,1.00) 141ns × (0.98,1.04) +1.88% (p=0.038)
BenchmarkRegexpMatchEasy1_1K-2 887ns × (0.99,1.01) 894ns × (0.99,1.01) ~ (p=0.087)
BenchmarkRegexpMatchMedium_32-2 252ns × (0.99,1.01) 252ns × (0.99,1.01) ~ (p=0.954)
BenchmarkRegexpMatchMedium_1K-2 73.4µs × (0.99,1.02) 72.8µs × (1.00,1.01) -0.87% (p=0.029)
BenchmarkRegexpMatchHard_32-2 3.95µs × (0.97,1.05) 3.87µs × (1.00,1.01) -2.11% (p=0.035)
BenchmarkRegexpMatchHard_1K-2 117µs × (0.99,1.01) 117µs × (0.99,1.01) ~ (p=0.669)
BenchmarkRevcomp-2 980ms × (0.95,1.03) 993ms × (0.94,1.09) ~ (p=0.527)
BenchmarkTemplate-2 136ms × (0.98,1.01) 135ms × (0.99,1.01) ~ (p=0.200)
BenchmarkTimeParse-2 630ns × (1.00,1.01) 630ns × (1.00,1.00) ~ (p=0.634)
BenchmarkTimeFormat-2 705ns × (0.99,1.01) 710ns × (0.98,1.02) ~ (p=0.174)

GOMAXPROCS=4
BenchmarkBinaryTree17-4 9.87s × (0.96,1.04) 9.75s × (0.96,1.03) ~ (p=0.178)
BenchmarkFannkuch11-4 4.35s × (1.00,1.01) 4.40s × (0.99,1.04) ~ (p=0.071)
BenchmarkFmtFprintfEmpty-4 85.8ns × (0.98,1.06) 85.6ns × (0.98,1.04) ~ (p=0.858)
BenchmarkFmtFprintfString-4 306ns × (0.99,1.03) 304ns × (0.97,1.02) ~ (p=0.470)
BenchmarkFmtFprintfInt-4 317ns × (0.98,1.01) 315ns × (0.98,1.02) -0.92% (p=0.044)
BenchmarkFmtFprintfIntInt-4 527ns × (0.99,1.01) 525ns × (0.98,1.01) ~ (p=0.164)
BenchmarkFmtFprintfPrefixedInt-4 421ns × (0.98,1.03) 417ns × (0.99,1.02) ~ (p=0.092)
BenchmarkFmtFprintfFloat-4 623ns × (0.98,1.02) 618ns × (0.98,1.03) ~ (p=0.172)
BenchmarkFmtManyArgs-4 2.09µs × (0.98,1.02) 2.09µs × (0.98,1.02) ~ (p=0.679)
BenchmarkGobDecode-4 18.6ms × (0.99,1.01) 18.6ms × (0.98,1.03) ~ (p=0.595)
BenchmarkGobEncode-4 15.0ms × (0.98,1.02) 15.1ms × (0.99,1.01) ~ (p=0.301)
BenchmarkGzip-4 659ms × (0.98,1.04) 660ms × (0.97,1.02) ~ (p=0.724)
BenchmarkGunzip-4 145ms × (0.98,1.04) 144ms × (0.99,1.04) ~ (p=0.671)
BenchmarkHTTPClientServer-4 139µs × (0.97,1.02) 138µs × (0.99,1.02) ~ (p=0.392)
BenchmarkJSONEncode-4 35.0ms × (0.99,1.02) 35.1ms × (0.98,1.02) ~ (p=0.777)
BenchmarkJSONDecode-4 119ms × (0.98,1.01) 118ms × (0.98,1.02) ~ (p=0.710)
BenchmarkMandelbrot200-4 6.02ms × (1.00,1.00) 6.02ms × (1.00,1.00) ~ (p=0.289)
BenchmarkGoParse-4 7.96ms × (0.99,1.01) 7.96ms × (0.99,1.01) ~ (p=0.884)
BenchmarkRegexpMatchEasy0_32-4 164ns × (0.98,1.04) 166ns × (0.97,1.04) ~ (p=0.221)
BenchmarkRegexpMatchEasy0_1K-4 540ns × (0.99,1.01) 552ns × (0.97,1.04) +2.10% (p=0.018)
BenchmarkRegexpMatchEasy1_32-4 140ns × (0.99,1.04) 142ns × (0.97,1.04) ~ (p=0.226)
BenchmarkRegexpMatchEasy1_1K-4 896ns × (0.99,1.03) 907ns × (0.97,1.04) ~ (p=0.155)
BenchmarkRegexpMatchMedium_32-4 255ns × (0.99,1.04) 255ns × (0.98,1.04) ~ (p=0.904)
BenchmarkRegexpMatchMedium_1K-4 73.4µs × (0.99,1.04) 73.8µs × (0.98,1.04) ~ (p=0.560)
BenchmarkRegexpMatchHard_32-4 3.93µs × (0.98,1.04) 3.95µs × (0.98,1.04) ~ (p=0.571)
BenchmarkRegexpMatchHard_1K-4 117µs × (1.00,1.01) 119µs × (0.98,1.04) +1.48% (p=0.048)
BenchmarkRevcomp-4 990ms × (0.94,1.08) 989ms × (0.94,1.10) ~ (p=0.957)
BenchmarkTemplate-4 137ms × (0.98,1.02) 137ms × (0.99,1.01) ~ (p=0.996)
BenchmarkTimeParse-4 629ns × (1.00,1.00) 629ns × (0.99,1.01) ~ (p=0.924)
BenchmarkTimeFormat-4 710ns × (0.99,1.01) 716ns × (0.98,1.02) +0.84% (p=0.033)

Change-Id: I43a04e0f6ad5e3ba9847dddf12e13222561f9cf4
Reviewed-on: https://go-review.googlesource.com/9543Reviewed-by: Austin Clements <austin@google.com>

79a990b8

doc/go1.5.txt: add Jacobi and Int.ModSqrt to math/big · a593a36b

Josh Bleecher Snyder authored Apr 30, 2015

Change-Id: I187e97592cd0403d84ca25c4acb1a4b25495041b
Reviewed-on: https://go-review.googlesource.com/9534Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

a593a36b

runtime: fix gcDumpObject on non-heap pointers · 3ca20218

Austin Clements authored Apr 29, 2015

gcDumpObject is used to print the source and destination objects when
checkmark find a missing mark. However, gcDumpObject currently assumes
the given pointer will point to a heap object. This is not true of the
source object during root marking and may not even be true of the
destination object in the limited situations where the heap points
back in to the stack.

If the pointer isn't a heap object, gcDumpObject will attempt an
out-of-bounds access to h_spans. This will cause a panicslice, which
will attempt to construct a useful panic message. This will cause a
string allocation, which will lead mallocgc to panic because the GC is
in mark termination (checkmark only happens during mark termination).

Fix this by checking that the pointer points into the heap arena
before attempting to use it as an arena pointer.

Change-Id: I09da600c380d4773f1f8f38e45b82cb229ea6382
Reviewed-on: https://go-review.googlesource.com/9498Reviewed-by: Rick Hudson <rlh@golang.org>

3ca20218

strings: use LastIndexByte in LastIndex · cfb8b18e

Dmitry Vyukov authored Apr 30, 2015

Change-Id: I1add1b92f5c2688a99133d90bf9789d770fd9f05
Reviewed-on: https://go-review.googlesource.com/9503Reviewed-by: Matthew Dempsky <mdempsky@google.com>

cfb8b18e

doc/go1.5.txt: bytes, strings: add LastIndexByte · 09edc5c6

Dmitry Vyukov authored Apr 30, 2015

Change-Id: I05cfacd746e87011de8b659ab3b2fbe23146a7f3
Reviewed-on: https://go-review.googlesource.com/9504Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

09edc5c6

bytes, strings: add LastIndexByte · 0fb5475b

Dmitry Vyukov authored Apr 29, 2015

Currently the packages have the following index functions:

func Index(s, sep []byte) int
func IndexAny(s []byte, chars string) int
func IndexByte(s []byte, c byte) int
func IndexFunc(s []byte, f func(r rune) bool) int
func IndexRune(s []byte, r rune) int

func LastIndex(s, sep []byte) int
func LastIndexAny(s []byte, chars string) int
func LastIndexFunc(s []byte, f func(r rune) bool) int

Searching for the last occurrence of a byte is quite common
for string parsing algorithms (e.g. find the last paren on a line).
Also addition of LastIndexByte makes the set more orthogonal.

Change-Id: Ida168849acacf8e78dd70c1354bef9eac5effafe
Reviewed-on: https://go-review.googlesource.com/9500Reviewed-by: Rob Pike <r@golang.org>

0fb5475b

mime, time, internal/syscall/windows/registry: use new registry package to simplify code · 89454b1c

Alex Brainman authored Apr 23, 2015

This CL copies golang.org/x/sys/windows/registry into
internal/syscall/windows/registry (minus KeyInfo.ModTime to prevent
dependency cycles). New registry package is used in mime and time
packages instead of calling Windows API directly.

Change-Id: I965a5a41d4739b3ba38e539a7b8d96d3223e3d56
Reviewed-on: https://go-review.googlesource.com/9271Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

89454b1c

math/big: add modular square-root and Jacobi functions · ac615882

Bryan Ford authored Dec 19, 2014

This change adds Int.ModSqrt to compute modular square-roots via the
standard Tonelli-Shanks algorithm, and the Jacobi function that this and
many other modular-arithmetic algorithms depend on.

This is needed by change 1883 (https://golang.org/cl/1883), to add
support for ANSI-standard compressed encoding of elliptic curve points.

Change-Id: Icc4805001bba0b3cb7200e0b0a7f87b14a9e9439
Reviewed-on: https://go-review.googlesource.com/1886Reviewed-by: Adam Langley <agl@golang.org>

ac615882

crypto/x509: be strict about trailing data. · 1ddb8c20

Adam Langley authored Apr 29, 2015

The X.509 parser was allowing trailing data after a number of structures
in certificates and public keys. There's no obvious security issue here,
esp in certificates which are signed anyway, but this change makes
trailing data an error just in case.

Fixes #10583

Change-Id: Idc289914899600697fc6d30482227ff4bf479241
Reviewed-on: https://go-review.googlesource.com/9473Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>

1ddb8c20

crypto/tls: update the supported signature algorithms. · 1c105980

Adam Langley authored Apr 29, 2015

This is the second in a two-part change. See https://golang.org/cl/9415
for details of the overall change.

This change updates the supported signature algorithms to include
SHA-384 and updates all the testdata/ files accordingly. Even some of
the testdata/ files named “TLS1.0” and “TLS1.1” have been updated
because they have TLS 1.2 ClientHello's even though the server picks a
lower version.

Fixes #9757.

Change-Id: Ia76de2b548d3b39cd4aa3f71132b0da7c917debd
Reviewed-on: https://go-review.googlesource.com/9472Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

1c105980

crypto/tls: decouple handshake signatures from the handshake hash. · 09b238f1

Adam Langley authored Apr 28, 2015

Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.

TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.

Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.

However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.

Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.

This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.

This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.

It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.

Much of this code was written by davidben@ for the purposes of testing
BoringSSL.

Partly addresses #9757

Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>

09b238f1

cmd/dist: rename buildmode method to supportedBuildmode · edcc8f9e

Ian Lance Taylor authored Apr 30, 2015

Change-Id: Ie36fd46ad3c0799200fdf4240483a207335570d8
Reviewed-on: https://go-review.googlesource.com/9531Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

edcc8f9e

doc: mention net.OpError in go1.5.txt · 433af05a

Mikio Hara authored Apr 29, 2015

Change-Id: I6cebaf42f2596c7f8fef3a67afb1e5ccb428d09c
Reviewed-on: https://go-review.googlesource.com/9521Reviewed-by: Ian Lance Taylor <iant@golang.org>

433af05a

src: build cmd in buildall.bash · 9b66cf60

Josh Bleecher Snyder authored Apr 29, 2015

This exercises the linker as well as the compiler.

Credit to Matthew Dempsky; see #10418.

Change-Id: I793947c0c617a34e23df766bff5238ff3ac3c0af
Reviewed-on: https://go-review.googlesource.com/9530Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

9b66cf60

29 Apr, 2015 8 commits

net/http: handle "close" amongst multiple Connection tokens · ae080c1a

Brad Fitzpatrick authored Apr 28, 2015

Fixes #8840

Change-Id: I194d0248734c15336f91a6bcf57ffcc9c0a3a435
Reviewed-on: https://go-review.googlesource.com/9434Reviewed-by: David Crawshaw <crawshaw@golang.org>

ae080c1a

misc/cgo/testshared: add basic test for -buildmode=shared/-linkshared · 0774f6db

Michael Hudson-Doyle authored Apr 27, 2015

Just a first basic test, I'll extend this to test more but want to get an
opinion on basic approach first.

Change-Id: Idab9ebd7d9960b000b81a01a1e53258bf4bce755
Reviewed-on: https://go-review.googlesource.com/9386Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

0774f6db

net: deflake timeout, deadline tests · 98e05562

Mikio Hara authored Apr 28, 2015

This change deflakes timeout, deadline tests, especially fixes socket
and goroutine leaks. Also adds a few missing tests that use features
introduced after go1 release.

Change-Id: Ibf73a4859f8d4a0ee494ca2fd180cbce72a7a2c7
Reviewed-on: https://go-review.googlesource.com/9464Reviewed-by: Ian Lance Taylor <iant@golang.org>

98e05562

cmd/internal/gc: cache commonly used Ptrto types · e64764c8

Josh Bleecher Snyder authored Apr 29, 2015

Reduces allocations in the compiler by ~1.5%.

No functional changes. Passes toolstash -cmp.

Change-Id: I2416f7fb0aaf9b7d6783c79e840039ad8fa7b5a3
Reviewed-on: https://go-review.googlesource.com/9419Reviewed-by: Russ Cox <rsc@golang.org>

e64764c8

net: consolidate listener test files · 2385f692

Mikio Hara authored Apr 28, 2015

This change merges unicast_posix_test.go and multicast_test.go into
listen_test.go before deflaking tests for Listen functions.

No code changes.

Change-Id: Ic4cd6531b95dfb5b6e6e254241692eca61a71e94
Reviewed-on: https://go-review.googlesource.com/9460Reviewed-by: Ian Lance Taylor <iant@golang.org>

2385f692

net: add missing Close tests · 4f38ef81

Mikio Hara authored Apr 29, 2015

This change adds missing CloseRead test and Close tests on Conn,
Listener and PacketConn with various networks.

Change-Id: Iadf99eaf526a323f853d203edc7c8d0577f67972
Reviewed-on: https://go-review.googlesource.com/9469Reviewed-by: Ian Lance Taylor <iant@golang.org>

4f38ef81

cmd/doc: show the true import path rather than "." · 1ab60c29

Rob Pike authored Apr 29, 2015

Change-Id: I7b15c027c15eefc2a004eb61491e828a7fbefc54
Reviewed-on: https://go-review.googlesource.com/9513Reviewed-by: Russ Cox <rsc@golang.org>

1ab60c29

net/http: Don't set Content-Length: -1 when responding to a POST · 632778c3

Peter Waldschmidt authored Apr 29, 2015

Fixes an issue where Response.Write writes out a Content-Length: -1
header when the corresponding Request is a POST or PUT and the
ContentLength was not previously set.

This was encountered when using httputil.DumpResponse
to write out the response from a server that responded to a PUT
request with no Content-Length header. The dumped output is
thus invalid.

Change-Id: I52c6ae8ef3443f1f9de92aeee9f9581dabb05991
Reviewed-on: https://go-review.googlesource.com/9496Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

632778c3