Commits · 7337181daf686714e2de88aa93c793ae441c94fa · go / golang

14 Apr, 2017 3 commits

net: validate network in Dial{,IP} and Listen{Packet,IP} for IP networks · 7337181d

Mikio Hara authored Apr 13, 2017

The argument of the first parameter for connection setup functions on
IP networks must contain a protocol name or number. This change adds
validation for arguments of IP networks to connection setup functions.

Fixes #18185.

Change-Id: I6aaedd7806e3ed1043d4b1c834024f350b99361d
Reviewed-on: https://go-review.googlesource.com/40512
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

7337181d

net: don't enclose non-literal IPv6 addresses in square brackets · dc74f51c

Mikio Hara authored Apr 12, 2017

The net package uses various textual representations for network
identifiers and locators on the Internet protocol suite as API.
In fact, the representations are the composition of subset of multple
RFCs: RFC 3986, RFC 4007, RFC 4632, RFC 4291 and RFC 5952.

RFC 4007 describes guidelines for the use of textual representation of
IPv6 addressing/routing scope zone and doesn't prohibit the format for
implementation dependent purposes, as in, specifying a literal IPv6
address and its connected region of routing topology as application
user interface. However, a non-literal IPv6 address, for example, a
host name, with a zone enclosed in square brackets confuses us because
a zone is basically for non-global IPv6 addresses and a pair of square
brackets is used as a set of delimiters between a literal IPv6 address
and a service name or transport port number.

To mitigate such confusion, this change makes JoinHostPort not enclose
non-literal IPv6 addresses in square brackets and SplitHostPort accept
the form "host%zone:port" to recommend that anything enclosed in
square brackets should be a literal IPv6 address.

Before this change:
	JoinHostPort("name%zone", "80") = "[name%zone]:80"
	JoinHostPort("[::1%zone]", "80") = "[::1%zone]:80"
	SplitHostPort("name%zone:80") = "", "", "address name%zone:80: missing brackets in address"
	SplitHostPort("[name%zone]:80") = "name%zone", "80", nil
	SplitHostPort("[::1%zone]:80") = "::1%zone", "80", nil

After this change:
	JoinHostPort("name%zone", "80") = "name%zone:80"
	JoinHostPort("[::1%zone]", "80") = "[::1%zone]:80"
	SplitHostPort("name%zone:80") = "name%zone", "80", nil
	SplitHostPort("[name%zone]:80") = "name%zone", "80", nil // for backwards compatibility
	SplitHostPort("[::1%zone]:80") = "::1%zone", "80", nil

Also updates docs and test cases on SplitHostPort and JoinHostPort for
clarification.

Fixes #18059.
Fixes #18060.

Change-Id: I5c3ccce4fa0fbdd58f698fc280635ea4a14d2a37
Reviewed-on: https://go-review.googlesource.com/40510
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

dc74f51c

cmd/dist: fix incorrect platform string shared by all tests · 1cf6d474

Wei Xiao authored Apr 13, 2017

all tests currently share the same platform string and fail to
vet expected platforms

Fixes #19958

Change-Id: I2801e1e84958e31975769581e27ea5ca6a0edf5b
Reviewed-on: https://go-review.googlesource.com/40511
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

1cf6d474

13 Apr, 2017 26 commits

syscall: fix TestGroupCleanup{UserNamespace} on Alpine · 75176947

Jess Frazelle authored Apr 13, 2017

This updates TestGroupCleanup and TestGroupCleanupUserNamespace to pass in the
Alpine builder.

Updates #19938

Change-Id: Iacbfd73782eccd57f872f9e85726c6024529c277
Reviewed-on: https://go-review.googlesource.com/40692Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>

75176947

cmd/compile: fix s390x unsigned comparison constant merging rules · f75b5e99

Michael Munday authored Apr 12, 2017

On s390x unsigned integer comparisons with immediates require the immediate
to be an unsigned 32-bit integer. The rule was checking that the immediate
was a signed 32-bit integer.

This CL also adds a test for comparisons that could be turned into compare
with immediate or equivalent instructions (depending on architecture and
optimizations applied).

Fixes #19940.

Change-Id: Ifd6aa989fd3d50e282f7d30fec9db462c28422b1
Reviewed-on: https://go-review.googlesource.com/40433
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>

f75b5e99

test: disable flaky test/fixedbugs/issue10958.go · dc09a7af

Brad Fitzpatrick authored Apr 13, 2017

Updates #18589

Change-Id: I2c3bbc8257c68295051bd2e63e1e11794d0609c3
Reviewed-on: https://go-review.googlesource.com/40651
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

dc09a7af

runtime: free workbufs during sweeping · 051809e3

Austin Clements authored Mar 20, 2017

This extends the sweeper to free workbufs back to the heap between GC
cycles, allowing this memory to be reused for GC'd allocations or
eventually returned to the OS.

This helps for applications that have high peak heap usage relative to
their regular heap usage (for example, a high-memory initialization
phase). Workbuf memory is roughly proportional to heap size and since
we currently never free workbufs, it's proportional to *peak* heap
size. By freeing workbufs, we can release and reuse this memory for
other purposes when the heap shrinks.

This is somewhat complicated because this costs ~1–2 µs per workbuf
span, so for large heaps it's too expensive to just do synchronously
after mark termination between starting the world and dropping the
worldsema. Hence, we do it asynchronously in the sweeper. This adds a
list of "free" workbuf spans that can be returned to the heap. GC
moves all workbuf spans to this list after mark termination and the
background sweeper drains this list back to the heap. If the sweeper
doesn't finish, that's fine, since getempty can directly reuse any
remaining spans to allocate more workbufs.

Performance impact is negligible. On the x/benchmarks, this reduces
GC-bytes-from-system by 6–11%.

Fixes #19325.

Change-Id: Icb92da2196f0c39ee984faf92d52f29fd9ded7a8
Reviewed-on: https://go-review.googlesource.com/38582
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

051809e3

runtime: allocate GC workbufs from manually-managed spans · 9cc883a4

Austin Clements authored Mar 20, 2017

Currently the runtime allocates workbufs from persistent memory, which
means they can never be freed.

Switch to allocating them from manually-managed heap spans. This
doesn't free them yet, but it puts us in a position to do so.

For #19325.

Change-Id: I94b2512a2f2bbbb456cd9347761b9412e80d2da9
Reviewed-on: https://go-review.googlesource.com/38581
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

9cc883a4

runtime: eliminate write barriers from alloc/mark bitmaps · 42c12147

Austin Clements authored Mar 24, 2017

This introduces a new type, *gcBits, to use for alloc/mark bitmap
allocations instead of *uint8. This type is marked go:notinheap, so
uses of it correctly eliminate write barriers. Since we now have a
type, this also extracts some common operations to methods both for
convenience and to avoid (*uint8) casts at most use sites.

For #19325.

Change-Id: Id51f734fb2e96b8b7715caa348c8dcd4aef0696a
Reviewed-on: https://go-review.googlesource.com/38580
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

42c12147

runtime: rename gcBits -> gcBitsArena · 9d1b2f88

Austin Clements authored Mar 24, 2017

This clarifies that the gcBits type is actually an arena of gcBits and
will let us introduce a new gcBits type representing a single
mark/alloc bitmap allocated from the arena.

For #19325.

Change-Id: Idedf76d202d9174a17c61bcca9d5539e042e2445
Reviewed-on: https://go-review.googlesource.com/38579
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

9d1b2f88

runtime: don't count manually-managed spans from heap_{inuse,sys} · dc0f0ab7

Austin Clements authored Mar 22, 2017

Currently, manually-managed spans are included in memstats.heap_inuse
and memstats.heap_sys, but when we export these stats to the user, we
subtract out how much has been allocated for stack spans from both.
This works for now because stacks are the only manually-managed spans
we have.

However, we're about to use manually-managed spans for more things
that don't necessarily have obvious stats we can use to adjust the
user-presented numbers. Prepare for this by changing the accounting so
manually-managed spans don't count toward heap_inuse or heap_sys. This
makes these fields align with the fields presented to the user and
means we don't have to track more statistics just so we can adjust
these statistics.

For #19325.

Change-Id: I5cb35527fd65587ff23339276ba2c3969e2ad98f
Reviewed-on: https://go-review.googlesource.com/38577
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>

dc0f0ab7

runtime: generalize {alloc,free}Stack to {alloc,free}Manual · 407c56ae

Austin Clements authored Mar 16, 2017

We're going to start using manually-managed spans for GC workbufs, so
rename the allocate/free methods and pass in a pointer to the stats to
use instead of using the stack stats directly.

For #19325.

Change-Id: I37df0147ae5a8e1f3cb37d59c8e57a1fcc6f2980
Reviewed-on: https://go-review.googlesource.com/38576
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>

407c56ae

runtime: rename mspan.stackfreelist -> manualFreeList · ab9db51e

Austin Clements authored Mar 16, 2017

We're going to use this free list for other types of manually-managed
memory in the heap.

For #19325.

Change-Id: Ib7e682295133eabfddf3a84f44db43d937bfdd9c
Reviewed-on: https://go-review.googlesource.com/38575
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

ab9db51e

runtime: rename _MSpanStack -> _MSpanManual · 8fbaa4f7

Austin Clements authored Mar 16, 2017

We're about to generalize _MSpanStack to be used for other forms of
in-heap manual memory management in the runtime. This is an automated
rename of _MSpanStack to _MSpanManual plus some comment fix-ups.

For #19325.

Change-Id: I1e20a57bb3b87a0d324382f92a3e294ffc767395
Reviewed-on: https://go-review.googlesource.com/38574
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

8fbaa4f7

cmd/compile: emit string symbols during walk · 16df2ccd

Josh Bleecher Snyder authored Apr 13, 2017

This avoids needing a mutex to protect stringsym,
and preserves a consistent ctxt.Data ordering
in the face of a concurrent backend.

Updates #15756

Change-Id: I775daae11db5db1269533a00f5249e3a03086ffc
Reviewed-on: https://go-review.googlesource.com/40509
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

16df2ccd

spec: clarify size hint for make of maps · b0e5a0c9

Robert Griesemer authored Apr 11, 2017

For #19903.

Change-Id: Ib28d08d45bfad653bcc1446f160b7b4a485529af
Reviewed-on: https://go-review.googlesource.com/40393Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

b0e5a0c9

cmd/compile: remove last c-isms from typecheck.go comments · 55b56d2b

Alberto Donizetti authored Apr 12, 2017

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

55b56d2b

cmd/internal/obj: cache dwarfSym · 7b5f94e7

Josh Bleecher Snyder authored Apr 13, 2017

Follow-up to review feedback from
mdempsky on CL 40507.

Reduces mutex contention by about 1%.

Change-Id: I540ea6772925f4a59e58f55a3458eff15880c328
Reviewed-on: https://go-review.googlesource.com/40575
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

7b5f94e7

cmd/compile: refactor Linksym · adc80c06

Josh Bleecher Snyder authored Apr 13, 2017

Extract a helper function, linksymname.
This simplifies Linksym,
and linksymname will be useful in future work.

Change-Id: Ic5ff8b704a16d5020f6931e008e2f630f687cbd3
Reviewed-on: https://go-review.googlesource.com/40550
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

adc80c06

cmd/internal/obj: generate function DWARF symbols early · 4e4e51c5

Josh Bleecher Snyder authored Apr 13, 2017

This removes a concurrent access of ctxt.Data.

Updates #15756

Change-Id: Id017e90e47e093cd8825907f3853bb3d3bf8280d
Reviewed-on: https://go-review.googlesource.com/40507
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

4e4e51c5

cmd/vet/all: print all unparseable lines · 7fa3b79c

Josh Bleecher Snyder authored Apr 13, 2017

In my experience, this usually happens when vet panics.
Dumping all unparseable lines should help diagnosis.

Inspired by the trybot failures in CL 40511.

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

7fa3b79c

hash/crc32: optimize arm64 crc32 implementation · ab636b89

Wei Xiao authored Mar 17, 2017

ARMv8 defines crc32 instruction.

Comparing to the original crc32 calculation, this patch makes use of
crc32 instructions to do crc32 calculation instead of the multiple
lookup table algorithms.

ARMv8 provides IEEE and Castagnoli polynomials for crc32 calculation
so that the perfomance of these two types of crc32 get significant
improved.

name old time/op new time/op delta
CRC32/poly=IEEE/size=15/align=0-32 117ns ± 0% 38ns ± 0% -67.44%
CRC32/poly=IEEE/size=15/align=1-32 117ns ± 0% 38ns ± 0% -67.52%
CRC32/poly=IEEE/size=40/align=0-32 129ns ± 0% 41ns ± 0% -68.37%
CRC32/poly=IEEE/size=40/align=1-32 129ns ± 0% 41ns ± 0% -68.29%
CRC32/poly=IEEE/size=512/align=0-32 828ns ± 0% 246ns ± 0% -70.29%
CRC32/poly=IEEE/size=512/align=1-32 828ns ± 0% 132ns ± 0% -84.06%
CRC32/poly=IEEE/size=1kB/align=0-32 1.58µs ± 0% 0.46µs ± 0% -70.98%
CRC32/poly=IEEE/size=1kB/align=1-32 1.58µs ± 0% 0.46µs ± 0% -70.92%
CRC32/poly=IEEE/size=4kB/align=0-32 6.06µs ± 0% 1.74µs ± 0% -71.27%
CRC32/poly=IEEE/size=4kB/align=1-32 6.10µs ± 0% 1.74µs ± 0% -71.44%
CRC32/poly=IEEE/size=32kB/align=0-32 48.3µs ± 0% 13.7µs ± 0% -71.61%
CRC32/poly=IEEE/size=32kB/align=1-32 48.3µs ± 0% 13.7µs ± 0% -71.60%
CRC32/poly=Castagnoli/size=15/align=0-32 116ns ± 0% 38ns ± 0% -67.07%
CRC32/poly=Castagnoli/size=15/align=1-32 116ns ± 0% 38ns ± 0% -66.90%
CRC32/poly=Castagnoli/size=40/align=0-32 127ns ± 0% 40ns ± 0% -68.11%
CRC32/poly=Castagnoli/size=40/align=1-32 127ns ± 0% 40ns ± 0% -68.11%
CRC32/poly=Castagnoli/size=512/align=0-32 828ns ± 0% 132ns ± 0% -84.06%
CRC32/poly=Castagnoli/size=512/align=1-32 827ns ± 0% 132ns ± 0% -84.04%
CRC32/poly=Castagnoli/size=1kB/align=0-32 1.59µs ± 0% 0.22µs ± 0% -85.89%
CRC32/poly=Castagnoli/size=1kB/align=1-32 1.58µs ± 0% 0.22µs ± 0% -85.79%
CRC32/poly=Castagnoli/size=4kB/align=0-32 6.14µs ± 0% 0.77µs ± 0% -87.40%
CRC32/poly=Castagnoli/size=4kB/align=1-32 6.06µs ± 0% 0.77µs ± 0% -87.25%
CRC32/poly=Castagnoli/size=32kB/align=0-32 48.3µs ± 0% 5.9µs ± 0% -87.71%
CRC32/poly=Castagnoli/size=32kB/align=1-32 48.4µs ± 0% 6.0µs ± 0% -87.69%
CRC32/poly=Koopman/size=15/align=0-32 104ns ± 0% 104ns ± 0% +0.00%
CRC32/poly=Koopman/size=15/align=1-32 104ns ± 0% 104ns ± 0% +0.00%
CRC32/poly=Koopman/size=40/align=0-32 235ns ± 0% 235ns ± 0% +0.00%
CRC32/poly=Koopman/size=40/align=1-32 235ns ± 0% 235ns ± 0% +0.00%
CRC32/poly=Koopman/size=512/align=0-32 2.71µs ± 0% 2.71µs ± 0% -0.07%
CRC32/poly=Koopman/size=512/align=1-32 2.71µs ± 0% 2.71µs ± 0% -0.04%
CRC32/poly=Koopman/size=1kB/align=0-32 5.40µs ± 0% 5.39µs ± 0% -0.06%
CRC32/poly=Koopman/size=1kB/align=1-32 5.40µs ± 0% 5.40µs ± 0% +0.02%
CRC32/poly=Koopman/size=4kB/align=0-32 21.5µs ± 0% 21.5µs ± 0% -0.16%
CRC32/poly=Koopman/size=4kB/align=1-32 21.5µs ± 0% 21.5µs ± 0% -0.05%
CRC32/poly=Koopman/size=32kB/align=0-32 172µs ± 0% 172µs ± 0% -0.07%
CRC32/poly=Koopman/size=32kB/align=1-32 172µs ± 0% 172µs ± 0% -0.01%

name old speed new speed delta
CRC32/poly=IEEE/size=15/align=0-32 128MB/s ± 0% 394MB/s ± 0% +207.95%
CRC32/poly=IEEE/size=15/align=1-32 128MB/s ± 0% 394MB/s ± 0% +208.09%
CRC32/poly=IEEE/size=40/align=0-32 310MB/s ± 0% 979MB/s ± 0% +216.07%
CRC32/poly=IEEE/size=40/align=1-32 310MB/s ± 0% 979MB/s ± 0% +216.16%
CRC32/poly=IEEE/size=512/align=0-32 618MB/s ± 0% 2074MB/s ± 0% +235.72%
CRC32/poly=IEEE/size=512/align=1-32 618MB/s ± 0% 3852MB/s ± 0% +523.55%
CRC32/poly=IEEE/size=1kB/align=0-32 646MB/s ± 0% 2225MB/s ± 0% +244.57%
CRC32/poly=IEEE/size=1kB/align=1-32 647MB/s ± 0% 2225MB/s ± 0% +243.87%
CRC32/poly=IEEE/size=4kB/align=0-32 676MB/s ± 0% 2352MB/s ± 0% +248.02%
CRC32/poly=IEEE/size=4kB/align=1-32 672MB/s ± 0% 2352MB/s ± 0% +250.15%
CRC32/poly=IEEE/size=32kB/align=0-32 678MB/s ± 0% 2387MB/s ± 0% +252.17%
CRC32/poly=IEEE/size=32kB/align=1-32 678MB/s ± 0% 2388MB/s ± 0% +252.11%
CRC32/poly=Castagnoli/size=15/align=0-32 129MB/s ± 0% 393MB/s ± 0% +205.51%
CRC32/poly=Castagnoli/size=15/align=1-32 129MB/s ± 0% 390MB/s ± 0% +203.41%
CRC32/poly=Castagnoli/size=40/align=0-32 314MB/s ± 0% 988MB/s ± 0% +215.04%
CRC32/poly=Castagnoli/size=40/align=1-32 314MB/s ± 0% 987MB/s ± 0% +214.68%
CRC32/poly=Castagnoli/size=512/align=0-32 618MB/s ± 0% 3860MB/s ± 0% +524.32%
CRC32/poly=Castagnoli/size=512/align=1-32 619MB/s ± 0% 3859MB/s ± 0% +523.66%
CRC32/poly=Castagnoli/size=1kB/align=0-32 645MB/s ± 0% 4568MB/s ± 0% +608.56%
CRC32/poly=Castagnoli/size=1kB/align=1-32 650MB/s ± 0% 4567MB/s ± 0% +602.94%
CRC32/poly=Castagnoli/size=4kB/align=0-32 667MB/s ± 0% 5297MB/s ± 0% +693.81%
CRC32/poly=Castagnoli/size=4kB/align=1-32 676MB/s ± 0% 5297MB/s ± 0% +684.00%
CRC32/poly=Castagnoli/size=32kB/align=0-32 678MB/s ± 0% 5519MB/s ± 0% +713.83%
CRC32/poly=Castagnoli/size=32kB/align=1-32 677MB/s ± 0% 5497MB/s ± 0% +712.04%
CRC32/poly=Koopman/size=15/align=0-32 143MB/s ± 0% 144MB/s ± 0% +0.27%
CRC32/poly=Koopman/size=15/align=1-32 143MB/s ± 0% 144MB/s ± 0% +0.33%
CRC32/poly=Koopman/size=40/align=0-32 169MB/s ± 0% 170MB/s ± 0% +0.12%
CRC32/poly=Koopman/size=40/align=1-32 170MB/s ± 0% 170MB/s ± 0% +0.08%
CRC32/poly=Koopman/size=512/align=0-32 189MB/s ± 0% 189MB/s ± 0% +0.07%
CRC32/poly=Koopman/size=512/align=1-32 189MB/s ± 0% 189MB/s ± 0% +0.04%
CRC32/poly=Koopman/size=1kB/align=0-32 190MB/s ± 0% 190MB/s ± 0% +0.05%
CRC32/poly=Koopman/size=1kB/align=1-32 190MB/s ± 0% 190MB/s ± 0% -0.01%
CRC32/poly=Koopman/size=4kB/align=0-32 190MB/s ± 0% 190MB/s ± 0% +0.15%
CRC32/poly=Koopman/size=4kB/align=1-32 190MB/s ± 0% 191MB/s ± 0% +0.05%
CRC32/poly=Koopman/size=32kB/align=0-32 191MB/s ± 0% 191MB/s ± 0% +0.06%
CRC32/poly=Koopman/size=32kB/align=1-32 191MB/s ± 0% 191MB/s ± 0% +0.02%

Also fix a bug of arm64 assembler

The optimization is mainly contributed by Fangming.Fang <fangming.fang@arm.com>

Change-Id: I900678c2e445d7e8ad9e2a9ab3305d649230905f
Reviewed-on: https://go-review.googlesource.com/40074Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

ab636b89

net/http/fcgi: expose cgi env vars in request context · aaf46821

Meir Fischer authored Apr 08, 2017

The current interface can't access all environment
variables directly or via cgi.RequestFromMap, which
only reads variables on its "white list" to be set on
the http.Request it returns. If an fcgi variable is
not on the "white list" - e.g. REMOTE_USER - the old
code has no access to its value.

This passes variables in the Request context that aren't
used to add data to the Request itself and adds a method
that parses those env vars from the Request's context.

Fixes #16546

Change-Id: Ibf933a768b677ece1bb93d7bf99a14cef36ec671
Reviewed-on: https://go-review.googlesource.com/40012
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

aaf46821

internal/poll: rename RecvFrom to ReadFrom for consistency · 7c3fa418

Mikio Hara authored Apr 12, 2017

Also adds missing docs.

Change-Id: Ibd8dbe8441bc7a41f01ed2e2033db98e479a5176
Reviewed-on: https://go-review.googlesource.com/40412
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

7c3fa418

cmd/compile: make TestAssembly resilient to output ordering · 0d36999a

Josh Bleecher Snyder authored Apr 06, 2017

To preserve reproducible builds, the text entries
during compilation will be sorted before being printed.
TestAssembly currently assumes that function init
comes after all user-defined functions.
Remove that assumption.
Instead of looking for "TEXT" to tell you where
a function ends--which may now yield lots of
non-function-code junk--look for a line beginning
with non-whitespace.

Updates #15756

Change-Id: Ibc82dba6143d769ef4c391afc360e523b1a51348
Reviewed-on: https://go-review.googlesource.com/39853
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

0d36999a

cmd/internal/obj: build ctxt.Text during Sym init · c18fd098

Josh Bleecher Snyder authored Apr 13, 2017

Instead of constructing ctxt.Text in Flushplist,
which will be called concurrently,
do it in InitTextSym, which must be called serially.
This allows us to avoid a mutex for ctxt.Text,
and preserves the existing ordering of functions
for debug output.

Passes toolstash-check.

Updates #15756

Change-Id: I6322b4da24f9f0db7ba25e5b1b50e8d3be2deb37
Reviewed-on: https://go-review.googlesource.com/40502
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

c18fd098

cmd/dist: don't compile unneeded GOARCH SSA rewrite rules during bootstrap · 9dbba36a

Brad Fitzpatrick authored Apr 13, 2017

Speeds up build (the bootstrap phase) by ~6 seconds.

Bootstrap goes from ~18 seconds to ~12 seconds.

Change-Id: I7e2ec8f5fc668bf6168d90098eaf70390b16e479
Reviewed-on: https://go-review.googlesource.com/40503
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

9dbba36a

hash/fnv: add 128-bit FNV hash support · e05de6a5

Lucas Clemente authored Mar 20, 2017

The 128bit FNV hash will be used e.g. in QUIC.

The algorithm is described at
https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function

Change-Id: I13f3ec39b0e12b7a5008824a6619dff2e708ee81
Reviewed-on: https://go-review.googlesource.com/38356
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

e05de6a5

encoding/asn1: support 31 bit identifiers with OID · 94aba766

Monis Khan authored Apr 12, 2017

The current implementation uses a max of 28 bits when decoding an
ObjectIdentifier.  This change makes it so that an int64 is used to
accumulate up to 35 bits.  If the resulting data would not overflow
an int32, it is used as an int.  Thus up to 31 bits may be used to
represent each subidentifier of an ObjectIdentifier.

Fixes #19933

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

94aba766

12 Apr, 2017 11 commits

os: handle relative symlinks starting with slash in Stat on windows · 8a2cc222

Hiroshi Ioka authored Apr 11, 2017

https://go-review.googlesource.com/c/39932/ handles relative symlinks.
But that change is incomplete.
We also have to handle relative symlinks starting with slash too.

Fixes #19937

Change-Id: I50dbccbaf270cb48a08fa57e5f450e5da18a7701
Reviewed-on: https://go-review.googlesource.com/40410Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

8a2cc222

cmd/compile: move Text.From.Sym initialization earlier · 3692925c

Josh Bleecher Snyder authored Apr 12, 2017

The initialization of an ATEXT Prog's From.Sym
can race with the assemblers in a concurrent compiler.
CL 40254 contains an initial, failed attempt to
fix that race.

This CL takes a different approach: Rather than
expose an API to initialize the Prog,
expose an API to initialize the Sym.

The initialization of the Sym can then be
moved earlier in the compiler, avoiding the race.

The growth of gc.Func has negligible
performance impact; see below.

Passes toolstash -cmp.

Updates #15756

name       old alloc/op      new alloc/op      delta
Template        38.8MB ± 0%       38.8MB ± 0%    ~     (p=0.968 n=9+10)
Unicode         29.8MB ± 0%       29.8MB ± 0%    ~     (p=0.684 n=10+10)
GoTypes          113MB ± 0%        113MB ± 0%    ~     (p=0.912 n=10+10)
SSA             1.25GB ± 0%       1.25GB ± 0%    ~     (p=0.481 n=10+10)
Flate           25.3MB ± 0%       25.3MB ± 0%    ~     (p=0.105 n=10+10)
GoParser        31.7MB ± 0%       31.8MB ± 0%  +0.09%  (p=0.016 n=8+10)
Reflect         78.3MB ± 0%       78.2MB ± 0%    ~     (p=0.190 n=10+10)
Tar             26.5MB ± 0%       26.6MB ± 0%  +0.13%  (p=0.011 n=10+10)
XML             42.4MB ± 0%       42.4MB ± 0%    ~     (p=0.971 n=10+10)

name       old allocs/op     new allocs/op     delta
Template          378k ± 1%         378k ± 0%    ~     (p=0.315 n=10+9)
Unicode           321k ± 1%         321k ± 0%    ~     (p=0.436 n=10+10)
GoTypes          1.14M ± 0%        1.14M ± 0%    ~     (p=0.079 n=10+9)
SSA              9.70M ± 0%        9.70M ± 0%  -0.04%  (p=0.035 n=10+10)
Flate             233k ± 1%         234k ± 1%    ~     (p=0.529 n=10+10)
GoParser          315k ± 0%         316k ± 0%    ~     (p=0.095 n=9+10)
Reflect           980k ± 0%         980k ± 0%    ~     (p=0.436 n=10+10)
Tar               249k ± 1%         250k ± 0%    ~     (p=0.280 n=10+10)
XML               391k ± 1%         391k ± 1%    ~     (p=0.481 n=10+10)

Change-Id: I3c93033dddd2e1df8cc54a106a6e615d27859e71
Reviewed-on: https://go-review.googlesource.com/40496
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

3692925c

net: delete TestDialTimeoutFDLeak · 7faf3024

Brad Fitzpatrick authored Apr 12, 2017

It's flaky and distracting.

I'm not sure what it's testing, either. It hasn't saved us before.

Somebody can resurrect it if they have time.

Updates #15157

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

7faf3024

cmd/internal/obj: stop storing Text flags in From3 · ce3ee7cd

Josh Bleecher Snyder authored Apr 11, 2017

Prior to this CL, flags such as NOSPLIT
on ATEXT Progs were stored in From3.Offset.
Some but not all of those flags were also
duplicated into From.Sym.Attribute.

This CL migrates all of those flags into
From.Sym.Attribute and stops creating a From3.

A side-effect of this is that printing an
ATEXT Prog can no longer simply dump From3.Offset.
That's kind of good, since the raw flag value
wasn't very informative anyway, but it did
necessitate a bunch of updates to the cmd/asm tests.

The reason I'm doing this work now is that
avoiding storing flags in both From.Sym and From3.Offset
simplifies some other changes to fix the data
race first described in CL 40254.

This CL almost passes toolstash-check -all.
The only changes are in cases where the assembler
has decided that a function's flags may be altered,
e.g. to make a function with no calls in it NOSPLIT.
Prior to this CL, that information was not printed.

Sample before:

"".Ctz64 t=1 size=63 args=0x10 locals=0x0
	0x0000 00000 (/Users/josh/go/tip/src/runtime/internal/sys/intrinsics.go:35)	TEXT	"".Ctz64(SB), $0-16
	0x0000 00000 (/Users/josh/go/tip/src/runtime/internal/sys/intrinsics.go:35)	FUNCDATA	$0, gclocals·f207267fbf96a0178e8758c6e3e0ce28(SB)

Sample after:

"".Ctz64 t=1 nosplit size=63 args=0x10 locals=0x0
	0x0000 00000 (/Users/josh/go/tip/src/runtime/internal/sys/intrinsics.go:35)	TEXT	"".Ctz64(SB), NOSPLIT, $0-16
	0x0000 00000 (/Users/josh/go/tip/src/runtime/internal/sys/intrinsics.go:35)	FUNCDATA	$0, gclocals·f207267fbf96a0178e8758c6e3e0ce28(SB)

Observe the additional "nosplit" in the first line
and the additional "NOSPLIT" in the second line.

Updates #15756

Change-Id: I5c59bd8f3bdc7c780361f801d94a261f0aef3d13
Reviewed-on: https://go-review.googlesource.com/40495
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

ce3ee7cd

cmd/compile/internal/ssa: refactor ARM64 address folding · 4eb48a33

Matthew Dempsky authored Apr 12, 2017

These patterns are the only uses of isArg and isAuto, and they all
follow a common pattern too. Extract out so that we can more easily
tweak the interface for isArg/isAuto.

Passes toolstash -cmp for linux/arm64.

Change-Id: I9c509dabdc123c93cb1ad2f34fe8c12a9f313f6d
Reviewed-on: https://go-review.googlesource.com/40490
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

4eb48a33

cmd/compile: do not print duplicate error on ideal->float{32,64} overflow · 2e60882f

Alberto Donizetti authored Apr 12, 2017

Also adjust truncfltlit to make it more similar to trunccmplxlit, and
make it report an error for bad Etypes.

Fixes #19947

Change-Id: I6684523e989c2293b8a8e85bd2bfb9c399c5ea36
Reviewed-on: https://go-review.googlesource.com/40453Reviewed-by: Robert Griesemer <gri@golang.org>

2e60882f

cmd/dist: require _ before GOOS and GOARCH when building bootstrap · c253ea47

Austin Clements authored Apr 12, 2017

Currently, dist allows GOOS and GOARCH to appear as *any* substring in
a file name when selecting source files to go into go_bootstrap. This
was necessary prior to Go 1.4, where it needed to match names like
"windows.c", but now it's gratuitously different from go/build. This
led to a bug chase to figure out why "stubs_nonlinux.go" was not being
built on non-Linux OSes.

Change shouldbuild to require an "_" before the GOOS and GOARCH in a
file name. This is still less strict than go/build, but the behavior
is much closer.

Change-Id: I580e9344a3c40d57c0721d345e911e8b4f141f5d
Reviewed-on: https://go-review.googlesource.com/40435
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

c253ea47

runtime: expand inlining iteratively in CallersFrames · 7f32d41e

Austin Clements authored Apr 12, 2017

Currently CallersFrames expands each PC to a slice of Frames and then
iteratively returns those Frames. However, this makes it very
difficult to avoid heap allocation: either the Frames slice will be
heap allocated, or, if it uses internal scratch space for small slices
(as it currently does), the Frames object itself has to be heap
allocated.

Fix this, at least in the common case, by expanding each PC
iteratively. We introduce a new pcExpander type that's responsible for
expanding a single PC. This maintains state from one Frame to the next
in the same PC. Frames then becomes a wrapper around this responsible
for feeding it the next PC when the pcExpander runs out of frames for
the current PC.

This makes it possible to stack-allocate a Frames object, which will
make it possible to use this API for PC expansion from within the
runtime itself.

Change-Id: I993463945ab574557cf1d6bedbe79ce7e9cbbdcd
Reviewed-on: https://go-review.googlesource.com/40434
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Lazar <lazard@golang.org>

7f32d41e

cmd/link: skip TestRuntimeTypeDIEs on Plan 9 · 746441f9

David du Colombier authored Apr 12, 2017

TestRuntimeTypeDIEs has been added in CL 38350. This
test is failing on Plan 9 because executables don't
have a DWARF symbol table.

Fixes #19944.

Change-Id: I121875bfd5f9f02ed668f8fb0686a0edffa2a99d
Reviewed-on: https://go-review.googlesource.com/40452
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

746441f9

cmd/compile/internal/ssa: ExternSymbol's Typ field is unused too · 700574e7

Matthew Dempsky authored Apr 12, 2017

Change-Id: I5b692eb0586c40f3735a6b9c928e97ffa00a70e6
Reviewed-on: https://go-review.googlesource.com/40471
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

700574e7

database/sql: correctly guard the query Row preventing early release · dec95d8f

Daniel Theophanes authored Apr 07, 2017

When a Tx starts a query, prevent returning the connection to the pool
until after the query finishes.

Fixes #19058

Change-Id: I2c0480d9cca9eeb173b5b3441a5aeed6f527e0ac
Reviewed-on: https://go-review.googlesource.com/40400Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

dec95d8f