Ilya Tocar [Fri, 21 Oct 2016 20:23:48 +0000 (23:23 +0300)]
bytes,strings: use IndexByte more often in Index on AMD64
IndexByte+compare is faster than indexShortStr in good case, when
first byte is rare, but is more costly in bad cases.
Start with IndexByte and switch to indexShortStr if we encounter
false positives more often than once per 8 bytes.
Brad Fitzpatrick [Tue, 1 Nov 2016 17:12:48 +0000 (17:12 +0000)]
net/http: add Transport.ProxyConnectHeader to control headers to proxies
Fixes #13290
Change-Id: I0f7e7683d86db501cbedb6a0b7349ceb0769701c
Reviewed-on: https://go-review.googlesource.com/32481 Reviewed-by: Martin Möhrmann <martisch@uos.de> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Bryan C. Mills [Thu, 27 Oct 2016 21:36:39 +0000 (17:36 -0400)]
runtime: align stack pointer in sigfwd
sigfwd calls an arbitrary C signal handler function. The System V ABI
for x86_64 (and the most recent revision of the ABI for i386) requires
the stack to be 16-byte aligned.
Fixes: #17641
Change-Id: I77f53d4a8c29c1b0fe8cfbcc8d5381c4e6f75a6b
Reviewed-on: https://go-review.googlesource.com/32107
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Brad Fitzpatrick [Tue, 1 Nov 2016 15:24:11 +0000 (15:24 +0000)]
net/http, net/http/httptest: make http2's TrailerPrefix work for http1
Go's http1 implementation originally had a mechanism to send HTTP
trailers based on pre-declaring the trailer keys whose values you'd
later let after the header was written.
http2 copied the same mechanism, but it was found to be unsufficient
for gRPC's wire protocol. A second trailer mechanism was added later
(but only to http2) for handlers that want to send a trailer without
knowing in advance they'd need to.
Copy the same mechanism back to http1 and document it.
Fixes #15754
Change-Id: I8c40d55e28b0e5b7087d3d1a904a392c56ee1f9b
Reviewed-on: https://go-review.googlesource.com/32479 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Lynn Boger [Tue, 1 Nov 2016 15:43:34 +0000 (10:43 -0500)]
cmd/vendor/golang.org/x/arch/ppc64/ppc64asm: skip TestObjdumpPowerManual if not ppc64x
Skip TestObjdumpPowerManual if the host system is not ppc64 or ppc64le.
This test depends on using the host objdump and comparing output, which
does not work as expected if the test is run on another host.
Orignates from golang.org/x/arch/ppc64/ppc64asm commit 8e2d4898.
David Crawshaw [Mon, 31 Oct 2016 12:59:05 +0000 (08:59 -0400)]
plugin: do not leak cRelName on error path
Fixes #17683
Change-Id: I46f45c63796b58e8a8f14e37592231cbe7cd6934
Reviewed-on: https://go-review.googlesource.com/32438 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
David Crawshaw [Mon, 31 Oct 2016 00:30:38 +0000 (20:30 -0400)]
runtime: access modules via a slice
The introduction of -buildmode=plugin means modules can be added to a
Go program while it is running. This means there exists some time
while the program is running with the module is on the moduledata
linked list, but it has not been initialized to the satisfaction of
other parts of the runtime. Notably, the GC.
This CL adds a new way of access modules, an activeModules function.
It returns a slice of modules that is built in the background and
atomically swapped in. The parts of the runtime that need to wait on
module initialization can use this slice instead of the linked list.
Fixes #17455
Change-Id: I04790fd07e40c7295beb47cea202eb439206d33d
Reviewed-on: https://go-review.googlesource.com/32357 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Munday [Fri, 7 Oct 2016 16:16:26 +0000 (12:16 -0400)]
cmd/compile: improve s390x rules for folding ADDconst into loads/stores
There is no benefit to folding ADDconsts unless the resultant immediate
will fit into a 20-bit signed integer, so limit these rules accordingly.
Also the signed load operations were missing, so I've added them, and
I've also removed some MOVDaddr rules that were dead code (MOVDaddrs
are rematerializable on s390x which means they can't take inputs other
than SP or SB).
Change-Id: Iebeba78da37d3d71d32d4b7f49fe4ea9095d40ec
Reviewed-on: https://go-review.googlesource.com/30616
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com>
Martin Möhrmann [Sat, 29 Oct 2016 23:54:19 +0000 (01:54 +0200)]
runtime: improve atoi implementation
- Adds overflow checks
- Adds parsing of negative integers
- Adds boolean return value to signal parsing errors
- Adds atoi32 for parsing of integers that fit in an int32
- Adds tests
Handling of errors to provide error messages
at the call sites is left to future CLs.
Updates #17718
Change-Id: I3cacd0ab1230b9efc5404c68edae7304d39bcbc0
Reviewed-on: https://go-review.googlesource.com/32390 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Daniel Martí [Thu, 27 Oct 2016 18:47:47 +0000 (19:47 +0100)]
testing: don't warn if -bench was passed
In a previous change, cmd/go was taught to show a "no tests ran" warning
if test did nothing. But it missed a case - if no tests nor examples ran
but any benchmarks were meant to be run, it would still produce the
warning. This meant that running only benchmarks, which is common, would
be confusing:
$ go test -run='^$' -bench=.
testing: warning: no tests to run
BenchmarkFoo-4 300000 5056 ns/op
[...]
I believe this was because of a copy-paste error in the tests. This was
being tested, but on the wrong file which does contain a test that was
being run. Fix the path and fix the now failing test by never showing
the warning if -bench was given a non-empty string.
The rationale is that if -bench was given but there was no output, it's
obvious that nothing happened as benchmarks always produce output even
without -v. So showing a warning in those cases is redundant.
To make future typos less likely, make sure that no tests are being run
in the cases where we only want to run benchmarks.
Fixes #17603.
Change-Id: I4c626caf39f72260c6a9761c06446663f465f947
Reviewed-on: https://go-review.googlesource.com/32157 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Emmanuel Odeke [Fri, 28 Oct 2016 15:11:39 +0000 (08:11 -0700)]
net/http/httputil: add ModifyResponse to reverseProxy
Adds ModifyResponse, an optional func to ReverseProxy
that modifies a response in the backend, right before
the headers of the response are written to the internal
response writer.
If ModifyResponse returns an error, the proxy returns
a StatusBadGateway error.
Joe Tsai [Tue, 1 Nov 2016 00:34:42 +0000 (17:34 -0700)]
encoding/json: marshal with null when RawMessage is nil
This CL expands upon a change made in (http://golang.org/cl/21811)
to ensure that a nil RawMessage gets serialized as "null" instead of
being a nil slice.
The added check only triggers when the RawMessage is nil. We do not
handle the case when the RawMessage is non-nil, but empty.
Austin Clements [Mon, 31 Oct 2016 21:37:05 +0000 (17:37 -0400)]
runtime: perform write barriers on direct channel receive
Currently we have write barriers for direct channel sends, where the
receiver is blocked and the sender is writing directly to the
receiver's stack; but not for direct channel receives, where the
sender is blocked and the receiver is reading directly from the
sender's stack.
This was okay with the old write barrier because either 1) the
receiver would write the received pointer into the heap (causing it to
be shaded), 2) the pointer would still be on the receiver's stack at
mark termination and we would rescan it, or 3) the receiver dropped
the pointer so it wasn't necessarily reachable anyway.
This is not okay with the write barrier because it lets a grey stack
send a white pointer to a black stack and then remove it from its own
stack. If the grey stack was the sole grey-protector of this pointer,
this hides the object from the garbage collector.
Fix this by making direct receives perform a stack-to-stack write
barrier just like direct sends do.
Fixes #17694.
Change-Id: I1a4cb904e4138d2ac22f96a3e986635534a5ae41
Reviewed-on: https://go-review.googlesource.com/32450 Reviewed-by: Rick Hudson <rlh@golang.org>
Dhananjay Nakrani [Sat, 29 Oct 2016 19:10:21 +0000 (12:10 -0700)]
cmd/compile: avoid nil-ing out a node's Type in typecheckcomplit() on error
typecheckcomplit nils out node's type, upon finding new errors.
This hides new errors in children's node as well as the type info
of current node. This change fixes that.
Fixes #17645.
Change-Id: Ib473291f31c7e8fa0307cb1d494e0c112ddd3583
Reviewed-on: https://go-review.googlesource.com/32324 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Austin Clements [Sun, 30 Oct 2016 21:59:06 +0000 (17:59 -0400)]
runtime: make assists perform root jobs
Currently, assists can only perform heap marking jobs. However, at the
beginning of GC, there are only root jobs and no heap marking jobs. As
a result, there's often a period at the beginning of a GC cycle where
no goroutine has accumulated assist credit, but at the same time it
can't get any credit because there are no heap marking jobs for it to
do yet. As a result, many goroutines often block on the assist queue
at the very beginning of the GC cycle.
This commit fixes this by allowing assists to perform root marking
jobs. The tricky part of this (and the reason we haven't done this
before) is that stack scanning jobs can lead to deadlocks if the
goroutines performing the stack scanning are themselves
non-preemptible, since two non-preemptible goroutines may try to scan
each other. To address this, we use the same insight d6625ca used to
simplify the mark worker stack scanning: as long as we're careful with
the stacks and only drain jobs while on the system stack, we can put
the goroutine into a preemptible state while we drain jobs. This means
an assist's user stack can be scanned while it continues to do work.
This reduces the rate of assist blocking in the x/benchmarks HTTP
benchmark by a factor of 3 and all remaining blocking happens towards
the *end* of the GC cycle, when there may genuinely not be enough work
to go around.
Ideally, assists would get credit for working on root jobs. Currently
they do not; however, this change prioritizes heap work over root jobs
in assists, so they're likely to mostly perform heap work. In contrast
with mark workers, for assists, the root jobs act only as a backstop
to create heap work when there isn't enough heap work.
Fixes #15361.
Change-Id: If6e169863e4ad75710b0c8dc00f6125b41e9a595
Reviewed-on: https://go-review.googlesource.com/32432 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Sun, 30 Oct 2016 21:46:49 +0000 (17:46 -0400)]
runtime: lift systemstack part of gcAssistAlloc
This lifts the part of gcAssistAlloc that runs on the system stack to
its own function in preparation for letting assists perform root jobs
(notably stack scanning). This makes it easy to see that there are no
references to the user stack once we've entered gcAssistAlloc1, which
means it's safe to shrink the stack while in gcAssistAlloc1.
This does not yet make assists perform root jobs, so it's not actually
possible for the stack to shrink yet. That will happen in the next
commit.
The code in gcAssistAlloc1 is identical to the code that's currently
passed in a closure to systemstack with one exception. Currently, we
set the "completed" variable in the enclosing scope to indicate that
the assist completed the mark phase. This is exactly the sort of
cross-stack reference lifting this function is meant to prevent. We
replace this variable with setting gp.param to nil or non-nil to
indicate the completion status.
Dhananjay Nakrani [Sun, 30 Oct 2016 19:47:53 +0000 (12:47 -0700)]
cmd/compile: initialize Decldepth in all cases
Previously, on encountering Func.Nname.Type == nil, typecheckfunc()
returned without initializing Decldepth for that func. This causes
typecheckclosure() to fatal. This change ensures that we initialize
Decldepth in all cases.
Keith Randall [Mon, 31 Oct 2016 04:10:03 +0000 (21:10 -0700)]
cmd/compile: make [0]T and [1]T SSAable types
We used to have to keep on-stack copies of these types.
Now they can be registerized.
[0]T is kind of trivial but might as well handle it.
This change enables another change I'm working on to improve how x.(T)
expressions are handled (#17405). This CL helps because now all
types that are direct interface types are registerizeable (e.g. [1]*byte).
No higher-degree arrays for now because non-constant indexes are hard.
Update #17405
Change-Id: I2399940965d17b3969ae66f6fe447a8cefdd6edd
Reviewed-on: https://go-review.googlesource.com/32416
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
David Chase [Fri, 28 Oct 2016 17:33:57 +0000 (13:33 -0400)]
cmd/compile: mark temps with new AutoTemp flag, and use it.
This is an extension of
https://go-review.googlesource.com/c/31662/
to mark all the temporaries, not just the ssa-generated ones.
Before-and-after ls -l `go tool -n compile` shows a 3%
reduction in size (or rather, a prior 3% inflation for
failing to filter temps out properly.)
Replaced name-dependent "is it a temp?" tests with calls to
*Node.IsAutoTmp(), which depends on AutoTemp. Also replace
calls to istemp(n) with n.IsAutoTmp(), to reduce duplication
and clean up function name space. Generated temporaries
now come with a "." prefix to avoid (apparently harmless)
clashes with legal Go variable names.
Fixes #17644.
Fixes #17240.
Change-Id: If1417f29c79a7275d7303ddf859b51472890fd43
Reviewed-on: https://go-review.googlesource.com/32255
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Matthew Dempsky [Mon, 31 Oct 2016 19:01:32 +0000 (12:01 -0700)]
cmd/compile: remove legacy debug flags
-M, -P, and -R were for debugging backend passes that no longer
exists.
-g is used for debugging instructions generated with Gins, but the SSA
backend mostly generates instructions directly. The handful of
instructions still generated with Gins are pretty useless for
debugging.
-x was used to debug the old lexer, but now it only causes us to print
file names as they're parsed, and only if we manually hack the
compiler to enable tracing.
Mike Strosaker [Fri, 28 Oct 2016 23:50:16 +0000 (19:50 -0400)]
crypto/sha256: improve performance for sha256.block on ppc64le
Adds an assembly implementation of sha256.block for ppc64le to improve its
performance. This implementation is largely based on the original amd64
implementation, which unrolls the 64 iterations of the inner loop.
Fixes #17652
benchmark old ns/op new ns/op delta
BenchmarkHash8Bytes 1263 767 -39.27%
BenchmarkHash1K 14048 7766 -44.72%
BenchmarkHash8K 102245 55626 -45.60%
benchmark old MB/s new MB/s speedup
BenchmarkHash8Bytes 6.33 10.43 1.65x
BenchmarkHash1K 72.89 131.85 1.81x
BenchmarkHash8K 80.12 147.27 1.84x
Change-Id: Ib4adf429423b20495580400be10bd7e171bcc70b
Reviewed-on: https://go-review.googlesource.com/32318 Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Mike Strosaker [Sat, 29 Oct 2016 06:36:41 +0000 (02:36 -0400)]
crypto/sha512: improve performance for sha512.block on ppc64le
Adds an assembly implementation of sha512.block for ppc64le to improve its
performance. This implementation is largely based on the original amd64
implementation, unrolling the 80 iterations of the inner loop.
Fixes #17660
benchmark old ns/op new ns/op delta
BenchmarkHash8Bytes 1715 1133 -33.94%
BenchmarkHash1K 10098 5513 -45.41%
BenchmarkHash8K 68004 35278 -48.12%
benchmark old MB/s new MB/s speedup
BenchmarkHash8Bytes 4.66 7.06 1.52x
BenchmarkHash1K 101.40 185.72 1.83x
BenchmarkHash8K 120.46 232.21 1.93x
Change-Id: Ifd55a49a24cb159b3a09a8e928c3f37727aca103
Reviewed-on: https://go-review.googlesource.com/32320 Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
David Crawshaw [Mon, 31 Oct 2016 01:19:59 +0000 (21:19 -0400)]
runtime: make module typemaps visible to the GC
The map[typeOff]*_type object is created at run time and stored in
the moduledata. The moduledata object is marked by the linker as
SNOPTRDATA, so the reference is ignored by the GC. Running
misc/cgo/testplugin/test.bash with GOGC=1 will eventually collect
the typemap and crash.
This bug probably comes up in -linkshared binaries in Go 1.7.
I don't know why we haven't seen a report about this yet.
Fixes #17680
Change-Id: I0e9b5c006010e8edd51d9471651620ba665248d3
Reviewed-on: https://go-review.googlesource.com/32430
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
David Crawshaw [Sun, 30 Oct 2016 19:31:21 +0000 (15:31 -0400)]
cmd/link, plugin: use full plugin path for symbols
Plumb the import path of a plugin package through to the linker, and
use it as the prefix on the exported symbol names.
Before this we used the basename of the plugin file as the prefix,
which could conflict and result in multiple loaded plugins sharing
symbols that are distinct.
Fixes #17155
Fixes #17579
Change-Id: I7ce966ca82d04e8507c0bcb8ea4ad946809b1ef5
Reviewed-on: https://go-review.googlesource.com/32355 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Gudger [Sat, 29 Oct 2016 03:09:02 +0000 (20:09 -0700)]
syscall: remove X__cmsg_data from Cmsghdr
This field is a zero length array and has little use. Since Go 1.5, trailing
zero-length arrays take up space. Both syscall.UnixRights() and
syscall.ParseSocketControlMessage() depend on being able to do an unsafe cast
of socket control message data to Cmsghdr this is only safe if the socket
control message data is greater than or equal to the size of Cmsghdr. Since
control message data that is equal in size to Cmsghdr without X__cmsg_data is
a valid socket control message, we must remove X__cmsg_data or not perform the
unsafe cast.
Removing X__cmsg_data will prevent Go code that uses X__cmsg_data from
compiling, but removing the unsafe cast will cause Go code that uses
X__cmsg_data to fail or exhibit undefined behavior at runtime. It was
therefore decided that removing X__cmsg_data was the better option.
Daniel Theophanes [Mon, 17 Oct 2016 06:11:55 +0000 (23:11 -0700)]
database/sql: add context helper methods and transaction types
Prior to this change, it was implied that transaction properties
would be carried in the context value. However, no such properties
were defined, not even common ones. Define two common properties:
isolation level and read-only. Drivers may choose to support
additional transaction properties. It is not expected any
further transaction properties will be added in the future.
Dmitry Vyukov [Fri, 28 Oct 2016 15:12:39 +0000 (17:12 +0200)]
runtime/race: update race runtime
This updates the runtime to HEAD to keep it aligned and fixes some bugs.
http://llvm.org/viewvc/llvm-project?view=revision&revision=285454
fixes the crash on darwin related to unaligned data section (#17065).
http://llvm.org/viewvc/llvm-project?view=revision&revision=285451
enables core dumps by default (#16527).
http://llvm.org/viewvc/llvm-project?view=revision&revision=285455
adds a hook to obtain number of races reported so far (#15972).
Can now be obtained with:
//go:nosplit
func RaceReportCount() int {
var n uint64
racecall(&__tsan_report_count, uintptr(unsafe.Pointer(&n)), 0, 0, 0)
return int(n)
}
Fixes #16527.
Fixes #17065.
Update #15972.
Change-Id: I8f869cb6275c9521a47303f3810a9965e9314357
Reviewed-on: https://go-review.googlesource.com/32160
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Joe Tsai [Sat, 29 Oct 2016 19:25:20 +0000 (12:25 -0700)]
compress/gzip: only encode MTIME if it is valid
The GZIP format records the ModTime as an uint32 counting seconds since
the Unix epoch. The zero value is explicitly defined in section 2.3.1
as meaning no timestamp is available.
Currently, the Writer always encodes the ModTime even if it is the zero
time.Time value, which causes the Writer to try and encode the value
-62135596800 into the uint32 MTIME field. This causes an overflow and
results in our GZIP files having MTIME fields indicating a date in 2042-07-13.
We alter the Writer to only encode ModTime if the value does not underflow
the MTIME field (i.e., it is newer than the Unix epoch). We do not attempt
to fix what happens when the timestamp overflows in the year 2106.
We alter the Reader to only decode ModTime if the value is non-zero.
There is no risk of overflowing time.Time when decoding.
Russ Cox [Tue, 25 Oct 2016 12:59:35 +0000 (08:59 -0400)]
cmd/link: fix -X importpath.name=value when import path needs escaping
After the final slash, dots are %-escaped when constructing a symbol name,
so that in the actual symbol table, the import path githost.com/my.git
becomes githost.com/my%2egit. In this case, -X githost.com/my.git.Value=foo
needs to set githost.com/my%2egit.Value. This is a detail of the object format
and not something users should know or depend on, so apply the escaping
as needed.
People who have run across this already and figured out and started using
the escaped forms with -X will find those forms not working anymore.
That is, -X githost.com/my%2egit.Value=foo is the Go 1.7 workaround but
will stop working in Go 1.8 once this proper fix is in place.
People who need to keep scripts working with older and newer versions of Go
can safely pass both forms, and one will be ignored:
Zev Goldstein [Fri, 28 Oct 2016 15:42:27 +0000 (11:42 -0400)]
path/filepath: fix Abs on Windows
The filepath.Abs function in windows did not call Clean as the
documentation claimed. This change not only fixes that behavior but
also adjusts TestAbs to verify Abs calls Clean as documented.
Fixes #17210
Change-Id: I20c5f5026042fd7bd9d929ff5b17c8b2653f8afe
Reviewed-on: https://go-review.googlesource.com/32292 Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
* Before:
./issue17631.go:20: unknown struct { about string; before map[string]uint;
update map[string]int; updateTime time.Time; expect map[string]int } field
'updates' in struct literal
* After:
./issue17631.go:20: unknown field 'updates' in struct literal of type { about string;
before map[string]uint; update map[string]int; updateTime time.Time;
expect map[string]int }
Dmitry Vyukov [Fri, 28 Oct 2016 22:53:49 +0000 (00:53 +0200)]
runtime/race: ignore user GORACE env var in tests
I did 'export GORACE=atexit_sleep_ms=0' in a console
and then was puzzled as to why race tests fail.
Existing GORACE env var may (or may not) override
the one that we setup.
Filter out GORACE as we do for other important env vars.
Than McIntosh [Fri, 28 Oct 2016 17:28:56 +0000 (13:28 -0400)]
test: add test for gccgo issue #17640
Change-Id: Iec35f9b62982da40de400397bc456149216303dc
Reviewed-on: https://go-review.googlesource.com/32297 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Ian Lance Taylor [Fri, 28 Oct 2016 22:25:31 +0000 (18:25 -0400)]
time: clarify Equal docs
The docs used to imply that using == would compare Locations, but of
course it just compares Location pointers, which will have unpredictable
results depending on how the pointers are loaded.
Peter Weinberger [Fri, 28 Oct 2016 19:12:18 +0000 (15:12 -0400)]
runtime: ensure elapsed cycles are not negative
On solaris/amd64 sometimes the reported cycle count is negative. Replace
with 0.
Change-Id: I364eea5ca072281245c7ab3afb0bf69adc3a8eae
Reviewed-on: https://go-review.googlesource.com/32258 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Fri, 28 Oct 2016 21:18:36 +0000 (17:18 -0400)]
runtime: fix SP adjustment on amd64p32
On amd64p32, rt0_go attempts to reserve 128 bytes of scratch space on
the stack, but due to a register mixup this ends up being a no-op. Fix
this so we actually reserve the stack space.
Change-Id: I04dbfbeb44f3109528c8ec74e1136bc00d7e1faa
Reviewed-on: https://go-review.googlesource.com/32331
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Sun, 23 Oct 2016 15:07:49 +0000 (11:07 -0400)]
runtime: disable stack rescanning by default
With the hybrid barrier in place, we can now disable stack rescanning
by default. This commit adds a "gcrescanstacks" GODEBUG variable that
is off by default but can be set to re-enable STW stack rescanning.
The plan is to leave this off but available in Go 1.8 for debugging
and as a fallback.
With this change, worst-case mark termination time at GOMAXPROCS=12
*not* including time spent stopping the world (which is still
unbounded) is reliably under 100 µs, with a 95%ile around 50 µs in
every benchmark I tried (the go1 benchmarks, the x/benchmarks garbage
benchmark, and the gcbench activegs and rpc benchmarks). Including
time spent stopping the world usually adds about 20 µs to total STW
time at GOMAXPROCS=12, but I've seen it add around 150 µs in these
benchmarks when a goroutine takes time to reach a safe point (see
issue #10958) or when stopping the world races with goroutine
switches. At GOMAXPROCS=1, where this isn't an issue, worst case STW
is typically 30 µs.
The go-gcbench activegs benchmark is designed to stress large numbers
of dirty stacks. This commit reduces 95%ile STW time for 500k dirty
stacks by nearly three orders of magnitude, from 150ms to 195µs.
This has little effect on the throughput of the go1 benchmarks or the
x/benchmarks benchmarks.
It reduces the tail latency of the x/benchmarks HTTP benchmark:
name old p50-time new p50-time delta
XHTTP-12 489µs ± 0% 491µs ± 1% +0.54% (p=0.000 n=20+18)
name old p95-time new p95-time delta
XHTTP-12 957µs ± 1% 960µs ± 1% +0.28% (p=0.002 n=20+17)
name old p99-time new p99-time delta
XHTTP-12 1.76ms ± 1% 1.64ms ± 1% -7.20% (p=0.000 n=20+18)
Comparing to the beginning of the hybrid barrier implementation
("runtime: parallelize STW mcache flushing") shows that the hybrid
barrier trades a small performance impact for much better STW latency,
as expected. The magnitude of the performance impact is generally
small:
Updates #17099, since you can't have a rescan list bug if there's no
rescan list. I'm not marking it as fixed, since gcrescanstacks can
still be set to re-enable the rescan lists.
Change-Id: I6e926b4c2dbd4cd56721869d4f817bdbb330b851
Reviewed-on: https://go-review.googlesource.com/31766 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Sun, 23 Oct 2016 15:03:56 +0000 (11:03 -0400)]
runtime: implement unconditional hybrid barrier
This implements the unconditional version of the hybrid deletion write
barrier, which always shades both the old and new pointer. It's
unconditional for now because barriers on channel operations require
checking both the source and destination stacks and we don't have a
way to funnel this information into the write barrier at the moment.
As part of this change, we modify the typed memclr operations
introduced earlier to invoke the write barrier.
This has basically no overall effect on benchmark performance. This is
good, since it indicates that neither the extra shade nor the new bulk
clear barriers have much effect. It also has little effect on latency.
This is expected, since we haven't yet modified mark termination to
take advantage of the hybrid barrier.
Updates #17503.
Change-Id: Iebedf84af2f0e857bd5d3a2d525f760b5cf7224b
Reviewed-on: https://go-review.googlesource.com/31765 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Wed, 26 Oct 2016 21:05:41 +0000 (17:05 -0400)]
runtime: avoid getfull() barrier most of the time
With the hybrid barrier, unless we're doing a STW GC or hit a very
rare race (~once per all.bash) that can start mark termination before
all of the work is drained, we don't need to drain the work queue at
all. Even draining an empty work queue is rather expensive since we
have to enter the getfull() barrier, so it's worth avoiding this.
Conveniently, it's quite easy to detect whether or not we actually
need the getufull() barrier: since the world is stopped when we enter
mark termination, everything must have flushed its work to the work
queue, so we can just check the queue. If the queue is empty and we
haven't queued up any jobs that may create more work (which should
always be the case with the hybrid barrier), we can simply have all GC
workers perform non-blocking drains.
Also conveniently, this solution is quite safe. If we do somehow screw
something up and there's work on the work queue, some worker will
still process it, it just may not happen in parallel.
This is not the "right" solution, but it's simple, expedient,
low-risk, and maintains compatibility with debug.gcrescanstacks. When
we remove the gcrescanstacks fallback in Go 1.9, we should also fix
the race that starts mark termination early, and then we can eliminate
work draining from mark termination.
Updates #17503.
Change-Id: I7b3cd5de6a248ab29d78c2b42aed8b7443641361
Reviewed-on: https://go-review.googlesource.com/32186 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Wed, 19 Oct 2016 19:49:31 +0000 (15:49 -0400)]
runtime: add deletion barriers on gobuf.ctxt
gobuf.ctxt is set to nil from many places in assembly code and these
assignments require write barriers with the hybrid barrier.
Conveniently, in most of these places ctxt should already be nil, in
which case we don't need the barrier. This commit changes these places
to assert that ctxt is already nil.
gogo is more complicated, since ctxt may not already be nil. For gogo,
we manually perform the write barrier if ctxt is not nil.
Austin Clements [Mon, 22 Aug 2016 20:02:54 +0000 (16:02 -0400)]
runtime: perform write barrier before pointer write
Currently, we perform write barriers after performing pointer writes.
At the moment, it simply doesn't matter what order this happens in, as
long as they appear atomic to GC. But both the hybrid barrier and ROC
are going to require a pre-write write barrier.
For the hybrid barrier, this is important because the barrier needs to
observe both the current value of the slot and the value that will be
written to it. (Alternatively, the caller could do the write and pass
in the old value, but it seems easier and more useful to just swap the
order of the barrier and the write.)
For ROC, this is necessary because, if the pointer write is going to
make the pointer reachable to some goroutine that it currently is not
visible to, the garbage collector must take some special action before
that pointer becomes more broadly visible.
This commits swaps pointer writes around so the write barrier occurs
before the pointer write.
The main subtlety here is bulk memory writes. Currently, these copy to
the destination first and then use the pointer bitmap of the
destination to find the copied pointers and invoke the write barrier.
This is necessary because the source may not have a pointer bitmap. To
handle these, we pass both the source and the destination to the bulk
memory barrier, which uses the pointer bitmap of the destination, but
reads the pointer values from the source.
Updates #17503.
Change-Id: I78ecc0c5c94ee81c29019c305b3d232069294a55
Reviewed-on: https://go-review.googlesource.com/31763 Reviewed-by: Rick Hudson <rlh@golang.org>
Cherry Zhang [Thu, 27 Oct 2016 18:33:58 +0000 (14:33 -0400)]
cmd/link: put text at address 0x1000000 on darwin/amd64
Apparently on macOS Sierra LLDB thinks /usr/lib/dyld is mapped
at address 0, even if Go code starts at 0x1000, and it looks up
addresses from dyld which shadows Go symbols. Move Go binary at
a higher address to avoid clash.
Austin Clements [Tue, 18 Oct 2016 14:26:28 +0000 (10:26 -0400)]
cmd/compile: disable various write barrier optimizations
Several of our current write barrier elision optimizations are invalid
with the hybrid barrier. Eliding the hybrid barrier requires that
*both* the current and new pointer be already shaded and, since we
don't have the flow analysis to figure out anything about the slot's
current value, for now we have to just disable several of these
optimizations.
This has a slight impact on binary size. On linux/amd64, the go tool
binary increases by 0.7% and the compile binary increases by 1.5%.
It also has a slight impact on performance, as one would expect. We'll
win some of this back in subsequent commits.
Austin Clements [Wed, 19 Oct 2016 20:16:40 +0000 (16:16 -0400)]
runtime: eliminate write barriers from save
As for dropg, save is writing a nil pointer that will generate a write
barrier with the hybrid barrier. However, in this case, ctxt always
should already be nil, so replace the write with an assertion that
this is the case.
At this point, we're ready to disable the write barrier elision
optimizations that interfere with the hybrid barrier.
Updates #17503.
Change-Id: I83208e65aa33403d442401f355b2e013ab9a50e9
Reviewed-on: https://go-review.googlesource.com/31571 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Wed, 19 Oct 2016 20:00:07 +0000 (16:00 -0400)]
runtime: eliminate write barriers from dropg
Currently this contains no write barriers because it's writing nil
pointers, but with the hybrid barrier, even these will produce write
barriers. However, since these are *gs and *ms, they don't need write
barriers, so we can simply eliminate them.
Updates #17503.
Change-Id: Ib188a60492c5cfb352814bf9b2bcb2941fb7d6c0
Reviewed-on: https://go-review.googlesource.com/31570 Reviewed-by: Rick Hudson <rlh@golang.org>
The hybrid barrier requires allocate-black, but there's one case where
we don't currently allocate black: the tiny allocator. If we allocate
a *new* tiny alloc block during GC, it will be allocated black, but if
we allocated the current block before GC, it won't be black, and the
further allocations from it won't mark it, which means we may free a
reachable tiny block during sweeping.
Fix this by passing over all mcaches at the beginning of mark, while
the world is still stopped, and greying their tiny blocks.
Updates #17503.
Change-Id: I04d4df7cc2f553f8f7b1e4cb0b52e2946588111a
Reviewed-on: https://go-review.googlesource.com/31456 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Thu, 13 Oct 2016 19:34:56 +0000 (15:34 -0400)]
runtime: shade stack-to-stack copy when starting a goroutine
The hybrid barrier requires barriers on stack-to-stack copies if
either stack is grey. There are only two instances of this in the
runtime: channel sends and starting a goroutine. Channel sends already
use typedmemmove and hence have the necessary barriers. This commits
adds barriers for the stack-to-stack copy when starting a goroutine.
Updates #17503.
Change-Id: Ibb55e08127ca4d021ac54be61cb96732efa5df5b
Reviewed-on: https://go-review.googlesource.com/31455 Reviewed-by: Rick Hudson <rlh@golang.org>
Michael Matloob [Fri, 28 Oct 2016 19:28:18 +0000 (15:28 -0400)]
runtime/pprof: write profiles in protobuf format.
Original Change by Daria Kolistratova <daria.kolistratova@intel.com>
Added functions with suffix proto and stuff from pprof tool to translate
to protobuf. Done as the profile proto is more extensible than the legacy
pprof format and is pprof's preferred profile format. Large part was taken
from https://github.com/google/pprof tool. Tested by hand and compared the
result with translated by pprof tool, profiles are identical.
Fixes #16093
Change-Id: I2751345b09a66ee2b6aa64be76cba4cd1c326aa6
Reviewed-on: https://go-review.googlesource.com/32257
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
Austin Clements [Wed, 26 Oct 2016 18:34:20 +0000 (14:34 -0400)]
runtime: zero-initialize LR on new stacks
Currently we initialize LR on a new stack by writing nil to it. But
this is an initializing write since the newly allocated stack is not
zeroed, so this is unsafe with the hybrid barrier. Change this is a
uintptr write to avoid a bad write barrier.
Updates #17503.
Change-Id: I062ac352e35df7da4644c1f2a5aaab87049d1f60
Reviewed-on: https://go-review.googlesource.com/32093 Reviewed-by: Rick Hudson <rlh@golang.org>