Yao Zhang [Thu, 10 Sep 2015 15:33:17 +0000 (11:33 -0400)]
cmd/cgo: added support for GOARCH=mips64{,le}
The actual cgo is not supported for now. This is just the cgo command.
Change-Id: I25625100ee552971f47e681b7d613cba16a2132f
Reviewed-on: https://go-review.googlesource.com/14446 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Minux Ma <minux@golang.org>
Yao Zhang [Thu, 10 Sep 2015 15:13:00 +0000 (11:13 -0400)]
cmd/internal/obj/mips: added support for GOARCH=mips64{,le}
MIPS64 has 32 general purpose 64-bit integer registers (R0-R31), 32
64-bit floating point registers (F0-F31). Instructions are fixed-width,
and are 32-bit wide. Instructions are all in standard 1-, 2-, 3-operand
forms.
MIPS64-specific relocations are added. For this reason, test data of
cmd/newlink are regenerated.
No other changes are made to portable structures.
Branch delay slots are current filled with NOP instructions. The function
for instruction scheduling (try to fill the delay slot with a useful
instruction) is implemented but disabled for now.
Change-Id: Ic364999c7a33245260c1381fc26a2fa8972d38b3
Reviewed-on: https://go-review.googlesource.com/14442 Reviewed-by: Minux Ma <minux@golang.org>
Matthew Dempsky [Thu, 12 Nov 2015 00:13:51 +0000 (16:13 -0800)]
runtime: rewrite lots of foo_Bar(f, ...) into f.bar(...)
Applies to types fixAlloc, mCache, mCentral, mHeap, mSpan, and
mSpanList.
Two special cases:
1. mHeap_Scavenge() previously didn't take an *mheap parameter, so it
was specially handled in this CL.
2. mHeap_Free() would have collided with mheap's "free" field, so it's
been renamed to (*mheap).freeSpan to parallel its underlying
(*mheap).freeSpanLocked method.
Change-Id: I325938554cca432c166fe9d9d689af2bbd68de4b
Reviewed-on: https://go-review.googlesource.com/16221 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Michael Hudson-Doyle [Thu, 12 Nov 2015 00:05:49 +0000 (13:05 +1300)]
runtime: run TestCgoExternalThreadSIGPROF on ppc64le
It was disabled because of the lack of external linking.
Change-Id: Iccb4a4ef8c57d048d53deabe4e0f4e6b9dccce33
Reviewed-on: https://go-review.googlesource.com/16797 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Hudson-Doyle [Tue, 27 Oct 2015 00:36:11 +0000 (13:36 +1300)]
cmd/go: handle linking against a shared library that implicitly includes a package
If you say "go install -buildmode=shared a b" and package a depends on another
package c, package c is implicitly included in the resulting shared library (as
specified by "Go Execution Modes"). But if c depends on b, linking against this
shared library hangs, because the go tool doesn't know when computing c's
dependencies that c is part of the same shared library as c.
Fix this by tracking the shared library a package *is* in separately from the
shared library a package has been explicitly linked into.
Fixes #13044
Change-Id: Iacfedab24ae9731ed53d225678b447a2a888823c
Reviewed-on: https://go-review.googlesource.com/16338
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Hudson-Doyle [Tue, 27 Oct 2015 21:40:46 +0000 (10:40 +1300)]
cmd/compile/internal/x86: avoid CX in a couple of places in the int64 code
I want to use CX as a scratch register in position independent code and these
uses are easy to remove.
Change-Id: I9e3cb470d7f0000d85786c30bd769d9ec86d532a
Reviewed-on: https://go-review.googlesource.com/16382 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Michael Hudson-Doyle [Tue, 27 Oct 2015 01:49:51 +0000 (14:49 +1300)]
cmd/link: fix size of filetab slice
The linker writes the number of file symbols (Nhistfile) to the filetab slice
and then Nhistfile offsets -- which means the slice contains Nhistfile+1
entries, not just Nhistfile.
I think this bug has been around since at least 1.4 but it's easier to trigger
with shared libraries and a tiny binary that only has a couple of functions in
it -- try go install -buildmode=shared std && go run -linkshared test/fixedbugs/issue4388.go.
Change-Id: I6c0f01f1e607b9b2b96872e37ffce81281911504
Reviewed-on: https://go-review.googlesource.com/16342
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Tue, 10 Nov 2015 20:24:59 +0000 (15:24 -0500)]
runtime: never allocate new M when jumping time forward
When we're jumping time forward, it means everyone is asleep, so there
should always be an M available. Furthermore, this causes both
allocation and write barriers in contexts that may be running without
a P (such as in sysmon).
Austin Clements [Tue, 10 Nov 2015 19:58:51 +0000 (14:58 -0500)]
runtime: replace traceBuf slice with index
Currently traceBuf keeps track of where it is in the trace buffer by
also maintaining a slice that points in to this buffer with an initial
length of 0 and a cap of the length of the array. All writes to this
buffer are done by appending to the slice (as long as the bounds
checks are right, it will never overflow and the append won't allocate
a new slice).
Each of these appends generates a write barrier. As long as we never
overflow the buffer, this write barrier won't fire, but this wreaks
havoc with eliminating write barriers from the tracing code. If we
were to overflow the buffer, this would both allocate and invoke a
write barrier, both things that are dicey at best to do in many of the
contexts tracing happens. It also wastes space in the traceBuf and
leads to more complex code and more complex generated code.
Replace this slice trick with keeping track of a simple array
position.
Austin Clements [Tue, 10 Nov 2015 19:37:52 +0000 (14:37 -0500)]
runtime: eliminate traceBuf write barriers
The tracing code is currently called from contexts such as sysmon and
the scheduler where write barriers are not allowed. Unfortunately,
while the common paths through the tracing code do not have write
barriers, many of the less common paths dealing with buffer overflow
and recycling do.
This change replaces all *traceBufs with traceBufPtrs. In the style of
guintptr, etc., the GC does not trace traceBufPtrs and write barriers
do not apply when these pointers are written. Since traceBufs are
allocated from non-GC'd memory and manually managed, this is always
safe.
Austin Clements [Fri, 30 Oct 2015 18:25:28 +0000 (14:25 -0400)]
runtime: fix over-aggressive proportional sweep
Currently, sweeping is performed before allocating a span by charging
for the entire size of the span requested, rather than the number of
bytes actually available for allocation from the returned span. That
is, if the returned span is 8K, but already has 6K in use, the mutator
is charged for 8K of heap allocation even though it can only allocate
2K more from the span. As a result, proportional sweep is
over-aggressive and tends to finish much earlier than it needs to.
This effect is more amplified by fragmented heaps.
Fix this by reimbursing the mutator for the used space in a span once
it has allocated that span. We still have to charge up-front for the
worst-case because we don't know which span the mutator will get, but
at least we can correct the over-charge once it has a span, which will
go toward later span allocations.
This has negligible effect on the throughput of the go1 benchmarks and
the garbage benchmark.
Fixes #12040.
Change-Id: I0e23e7a4ccf126cca000fed5067b20017028dd6b
Reviewed-on: https://go-review.googlesource.com/16515 Reviewed-by: Rick Hudson <rlh@golang.org>
Ian Lance Taylor [Wed, 4 Nov 2015 20:30:30 +0000 (12:30 -0800)]
runtime: don't call msanread when running on the system stack
The runtime is not instrumented, but the calls to msanread in the
runtime can sometimes refer to the system stack. An example is the call
to copy in stkbucket in mprof.go. Depending on what C code has done,
the system stack may appear uninitialized to msan.
Change-Id: Ic21705b9ac504ae5cf7601a59189302f072e7db1
Reviewed-on: https://go-review.googlesource.com/16660 Reviewed-by: David Crawshaw <crawshaw@golang.org>
Ian Lance Taylor [Wed, 4 Nov 2015 01:15:30 +0000 (17:15 -0800)]
runtime: mark cgo callback results as written for msan
This is a fix for the -msan option when using cgo callbacks. A cgo
callback works by writing out C code that puts a struct on the stack and
passes the address of that struct into Go. The result parameters are
fields of the struct. The Go code will write to the result parameters,
but the Go code thinks it is just writing into the Go stack, and
therefore won't call msanwrite. This CL adds a call to msanwrite in the
cgo callback code so that the C knows that results were written.
Change-Id: I80438dbd4561502bdee97fad3f02893a06880ee1
Reviewed-on: https://go-review.googlesource.com/16611 Reviewed-by: David Crawshaw <crawshaw@golang.org>
Austin Clements [Fri, 30 Oct 2015 02:40:36 +0000 (22:40 -0400)]
runtime: clean up park messages
This changes "mark worker (idle)" to "GC worker (idle)" so it's more
clear to users that these goroutines are GC-related. It changes "GC
assist" to "GC assist wait" to make it clear that the assist is
blocked.
Change-Id: Iafbc0903c84f9250ff6bee14baac6fcd4ed5ef76
Reviewed-on: https://go-review.googlesource.com/16511 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Tue, 27 Oct 2015 21:48:18 +0000 (17:48 -0400)]
runtime: free stack spans outside STW
We couldn't do this before this point because it must be done before
the next GC cycle starts. Hence, if it delayed the start of the next
cycle, that would widen the window between reaching the heap trigger
of the next cycle and starting the next GC cycle, during which the
mutator could over-allocate. With the decentralized GC, any mutators
that reach the heap trigger will block on the GC starting, so it's
safe to widen the time between starting the world and being able to
start the next GC cycle.
Ian Lance Taylor [Fri, 16 Oct 2015 22:26:00 +0000 (15:26 -0700)]
cmd/cgo, runtime: add checks for passing pointers from Go to C
This implements part of the proposal in issue 12416 by adding dynamic
checks for passing pointers from Go to C. This code is intended to be
on at all times. It does not try to catch every case. It does not
implement checks on calling Go functions from C.
The new cgo checks may be disabled using GODEBUG=cgocheck=0.
Ralph Corderoy [Sat, 7 Nov 2015 11:45:00 +0000 (11:45 +0000)]
crypto/tls: len(clientRandom) used for serverRandom source
In keysFromMasterSecret(), don't copy from serverRandom into
seed[:len(clientRandom)]. Actually, switch from an array to a slice in
keysFromMasterSecret() and masterFromPreMasterSecret() so the length
need not be given; that's how it's done elsewhere in the file.
Fixes #13181
Change-Id: I92abaa892d1bba80c2d4f12776341cda7d538837
Reviewed-on: https://go-review.googlesource.com/16697
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
“Literal IPv4 and IPv6 addresses are not permitted in "HostName".”
However, if an IP literal was set as Config.ServerName (which could
happen as easily as calling Dial with an IP address) then the code would
send the IP literal as the SNI value.
This change filters out IP literals, as recognised by net.ParseIP, from
being sent as the SNI value.
This is based on the implementation used in OpenSSL, from a
submission by Shay Gueron and myself. Besides using assembly,
this implementation employs several optimizations described in:
S.Gueron and V.Krasnov, "Fast prime field elliptic-curve
cryptography with 256-bit primes"
In addition a new and improved modular inverse modulo N is
implemented here.
The performance measured on a Haswell based Macbook Pro shows 21X
speedup for the sign and 9X for the verify operations.
The operation BaseMult is 30X faster (and the Diffie-Hellman/ECDSA
key generation that use it are sped up as well).
The adaptation to Go with the help of Filippo Valsorda
Updated the submission for faster verify/ecdh, fixed some asm syntax
and API problems and added benchmarks.
Change-Id: I86a33636747d5c92f15e0c8344caa2e7e07e0028
Reviewed-on: https://go-review.googlesource.com/8968
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
Ian Lance Taylor [Tue, 10 Nov 2015 19:25:15 +0000 (11:25 -0800)]
cmd/go: always use --whole-archive for gccgo packages
This is, in effect, what the gc toolchain does. It fixes cases where Go
code refers to a C global variable; without this, if the global variable
was the only thing visible in the C code, the generated cgo file might
not get pulled in from the archive, leaving the Go variable
uninitialized.
This was reported against gccgo as https://gcc.gnu.org/PR68255 .
Change-Id: I3e769dd174f64050ebbff268fbbf5e6fab1e2a1b
Reviewed-on: https://go-review.googlesource.com/16775
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
Michael Hudson-Doyle [Sun, 5 Jul 2015 09:49:11 +0000 (21:49 +1200)]
cmd/internal/obj/arm: access global data via GOT on arm when -dynlink
Change-Id: I88034611f56cc06bb47b0c431075cc78ca8dbb09
Reviewed-on: https://go-review.googlesource.com/14188 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Matloob [Mon, 2 Nov 2015 19:09:24 +0000 (14:09 -0500)]
runtime: break atomics out into package runtime/internal/atomic
This change breaks out most of the atomics functions in the runtime
into package runtime/internal/atomic. It adds some basic support
in the toolchain for runtime packages, and also modifies linux/arm
atomics to remove the dependency on the runtime's mutex. The mutexes
have been replaced with spinlocks.
all trybots are happy!
In addition to the trybots, I've tested on the darwin/arm64 builder,
on the darwin/arm builder, and on a ppc64le machine.
Erik Dubbelboer [Thu, 27 Aug 2015 06:09:15 +0000 (14:09 +0800)]
net/http: Show more data for unsolicited response
Show more than one character when we recieve a unsolicited
response on an idle HTTP channel. Showing more than one
byte is really useful when you want to debug your program
when you get this message.
Mohit Agarwal [Mon, 9 Nov 2015 20:22:52 +0000 (01:52 +0530)]
misc/cgo/testsanitizers: fix check for existence of clang
The current mechanism fails if clang cannot be executed by the current
user. Using the `-x` operator for `test` return TRUE if the file is
executable by the user.
Change-Id: I0f3c8dc3880c1ce5a8a833ff3109eb96853184af
Reviewed-on: https://go-review.googlesource.com/16752 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Hudson-Doyle [Thu, 3 Sep 2015 20:31:43 +0000 (08:31 +1200)]
cmd/dist: run more cgo tests on ppc64x
Change-Id: I992655bb02690ad95122a9e4c45cbd0948b545a0
Reviewed-on: https://go-review.googlesource.com/14238 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Alex Brainman [Fri, 6 Nov 2015 06:29:27 +0000 (17:29 +1100)]
net: fix off by one error while counting interfaces on windows
Fixes #12301
Change-Id: I8d01ec9551c6cff7e6129e06a7deb36a3be9de41
Reviewed-on: https://go-review.googlesource.com/16751 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Dominik Honnef [Wed, 28 Oct 2015 07:10:46 +0000 (08:10 +0100)]
html/template, encoding/asn1: fix test errors
Change-Id: I1da1d718609eb6a7b78d29b173ec780bde22c687
Reviewed-on: https://go-review.googlesource.com/16422 Reviewed-by: Ralph Corderoy <ralph@inputplus.co.uk> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
“Literal IPv4 and IPv6 addresses are not permitted in "HostName".”
However, if an IP literal was set as Config.ServerName (which could
happen as easily as calling Dial with an IP address) then the code would
send the IP literal as the SNI value.
This change filters out IP literals, as recognised by net.ParseIP, from
being sent as the SNI value.
Mohit Agarwal [Mon, 9 Nov 2015 19:26:14 +0000 (00:56 +0530)]
cmd/go: clean the directory path containing the packages
The heuristic for determining if the packages or commands are stale
fails as the mtime comparison happens even though the GOROOT and
current package paths are the same, since the path name isn't
canonicalized before the comparison (GOROOT is).
Fixes: #12690
Change-Id: Ia7d142fbbed8aac2bd2f71d1db4efd1f3ff5aece
Reviewed-on: https://go-review.googlesource.com/16483 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Keith Randall [Sun, 8 Nov 2015 05:28:21 +0000 (21:28 -0800)]
runtime: simplify chan ops, take 2
This change is the same as CL #9345 which was reverted,
except for a small bug fix.
The only change is to the body of sendDirect and its callsite.
Also added a test.
The problem was during a channel send operation. The target
of the send was a sleeping goroutine waiting to receive. We
basically do:
1) Read the destination pointer out of the sudog structure
2) Copy the value we're sending to that destination pointer
Unfortunately, the previous change had a goroutine suspend
point between 1 & 2 (the call to sendDirect). At that point
the destination goroutine's stack could be copied (shrunk).
The pointer we read in step 1 is no longer valid for step 2.
Fixed by not allowing any suspension points between 1 & 2.
I suspect the old code worked correctly basically by accident.
Fixes #13169
The original 9345:
This change removes the retry mechanism we use for buffered channels.
Instead, any sender waking up a receiver or vice versa completes the
full protocol with its counterpart. This means the counterpart does
not need to relock the channel when it wakes up. (Currently
buffered channels need to relock on wakeup.)
For sends on a channel with waiting receivers, this change replaces
two copies (sender->queue, queue->receiver) with one (sender->receiver).
For receives on channels with a waiting sender, two copies are still required.
This change unifies to a large degree the algorithm for buffered
and unbuffered channels, simplifying the overall implementation.
Fixes #11506
Change-Id: I57dfa3fc219cffa4d48301ee15fe5479299efa09
Reviewed-on: https://go-review.googlesource.com/16740 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Hudson-Doyle [Wed, 2 Sep 2015 10:25:57 +0000 (22:25 +1200)]
cmd/link, runtime: arm implementation of addmoduledata
Change-Id: I3975e10c2445e23c2798a7203a877ff2de3427c7
Reviewed-on: https://go-review.googlesource.com/14189 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Tamir Duberstein [Sun, 8 Nov 2015 00:30:25 +0000 (19:30 -0500)]
cmd/internal/ld: skip dwarf output if dsymutil no-ops
Fixes #11994.
Change-Id: Icee6ffa6e3a9d15b68b4ae9b2716d65ecbdba73a
Reviewed-on: https://go-review.googlesource.com/16702 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Brad Fitzpatrick [Sun, 8 Nov 2015 10:45:04 +0000 (11:45 +0100)]
net/http: update bundled http2 revision
Updates to git rev 042ba42f (https://golang.org/cl/16734)
This moves all the code for glueing the HTTP1 and HTTP2 transports
together out of net/http and into x/net/http2 where others can use it,
and where it has tests.
Keith Randall [Thu, 5 Nov 2015 20:39:56 +0000 (12:39 -0800)]
runtime: memmove/memclr pointers atomically
Make sure that we're moving or zeroing pointers atomically.
Anything that is a multiple of pointer size and at least
pointer aligned might have pointers in it. All the code looks
ok except for the 1-pointer-sized moves.
Keith Randall [Fri, 6 Nov 2015 08:06:52 +0000 (00:06 -0800)]
runtime: teach peephole optimizer that duffcopy clobbers X0
Duffcopy now uses X0, as of 5cf281a. Teach the peephole
optimizer that duffcopy clobbers X0 so that it does not
rename registers use X0 across the duffcopy instruction.
Fixes #13171
Change-Id: I389cbf1982cb6eb2f51e6152ac96736a8589f085
Reviewed-on: https://go-review.googlesource.com/16715
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Minux Ma <minux@golang.org> Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
Joe Tsai [Thu, 1 Oct 2015 09:30:29 +0000 (02:30 -0700)]
archive/tar: detect truncated files
Motivation:
* Reader.skipUnread never reports io.ErrUnexpectedEOF. This is strange
given that io.ErrUnexpectedEOF is given through Reader.Read if the
user manually reads the file.
* Reader.skipUnread fails to detect truncated files since io.Seeker
is lazy about reporting errors. Thus, the behavior of Reader differs
whether the input io.Reader also satisfies io.Seeker or not.
To solve this, we seek to one before the end of the data section and
always rely on at least one call to io.CopyN. If the tr.r satisfies
io.Seeker, this is guarunteed to never read more than blockSize.
David du Colombier [Thu, 5 Nov 2015 09:20:32 +0000 (10:20 +0100)]
cmd/go: skip TestBuildOutputToDevNull on Plan 9
TestBuildOutputToDevNull was added in CL 16585.
However, copying to /dev/null couldn't work on Plan 9,
because /dev/null is a regular file. Since it's not
different from any other file, the logic in copyFile
couldn't distinguish it from another, already existing,
file, that we wouldn't want to overwrite.
Change-Id: Ie8d353f318fedfc7cfb9541fed00a2397e232592
Reviewed-on: https://go-review.googlesource.com/16691 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: David du Colombier <0intro@gmail.com>
Michael Hudson-Doyle [Thu, 5 Nov 2015 21:10:07 +0000 (10:10 +1300)]
cmd/internal/obj/ppc64: fix assembly of SRADCC with immediate
sradi and sradi. hide the top bit of their immediate argument apart from the
rest of it, but the code only handled the sradi case.
I'm pretty sure this is the only instruction missing (a couple of the rotate
instructions encode their immediate the same way but their handling looks OK).
This fixes the failure of "GOARCH=amd64 ~/go/bin/go install -v runtime" as
reported in the bug.
Fixes #11987
Change-Id: I0cdefcd7a04e0e8fce45827e7054ffde9a83f589
Reviewed-on: https://go-review.googlesource.com/16710 Reviewed-by: Minux Ma <minux@golang.org>
David du Colombier [Thu, 5 Nov 2015 08:41:55 +0000 (09:41 +0100)]
cmd/go: skip TestGoGenerateEnv on Plan 9
TestGoGenerateEnv was added in CL 16537.
However, Plan 9 doesn't have the env command.
Change-Id: I5f0c937a1b9b456dcea41ceac7865112f2f65c45
Reviewed-on: https://go-review.googlesource.com/16690 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: David du Colombier <0intro@gmail.com>
Austin Clements [Tue, 27 Oct 2015 21:34:11 +0000 (17:34 -0400)]
runtime: remove GC start up/shutdown workaround in mallocgc
Currently mallocgc detects if the GC is in a state where it can't
assist, but also can't allocate uncontrolled and yields to help out
the GC. This was a workaround for periods when we were trying to
schedule the GC coordinator. It is no longer necessary because there
is no GC coordinator and malloc can always assist with any GC
transitions that are necessary.
Austin Clements [Mon, 26 Oct 2015 15:27:37 +0000 (11:27 -0400)]
runtime: decentralize mark done and mark termination
This moves all of the mark 1 to mark 2 transition and mark termination
to the mark done transition function. This means these transitions are
now handled on the goroutine that detected mark completion. This also
means that the GC coordinator and the background completion barriers
are no longer used and various workarounds to yield to the coordinator
are no longer necessary. These will be removed in follow-up commits.
One consequence of this is that mark workers now need to be
preemptible when performing the mark done transition. This allows them
to stop the world and to perform the final clean-up steps of GC after
restarting the world. They are only made preemptible while performing
this transition, so if the worker findRunnableGCWorker would schedule
isn't available, we didn't want to schedule it anyway.
Austin Clements [Mon, 26 Oct 2015 20:48:36 +0000 (16:48 -0400)]
runtime: account mark worker time before gcMarkDone
Currently gcMarkDone takes basically no time, so it's okay to account
the worker time after calling it. However, gcMarkDone is about to take
potentially *much* longer because it may perform all of mark
termination. Prepare for this by swapping the order so we account the
time before calling gcMarkDone.
Austin Clements [Sun, 25 Oct 2015 01:30:59 +0000 (21:30 -0400)]
runtime: factor mark done transition
Currently the code for completion of mark 1/mark 2 is duplicated in
background workers and assists. Factor this in to a single function
that will serve as the transition function for concurrent mark.
Austin Clements [Fri, 23 Oct 2015 21:44:11 +0000 (17:44 -0400)]
runtime: eliminate mark completion in scheduler
Currently, findRunnableGCWorker will perform mark completion if there
is no remaining work and no running workers. This used to be necessary
to resolve a race in the transition from mark 1 to mark 2 where we
would enter mark 2 with no mark work (and no dedicated workers), so no
workers would run, so no worker would signal mark completion.
However, we're about to make mark completion also perform the entire
follow-on process, which includes mark termination. We really don't
want to do that in the scheduler if it happens to detect completion.
Conveniently, this hack is no longer necessary because we always
enqueue root scanning work at the beginning of both mark 1 and mark 2,
so a mark worker will always run. Hence, we can simply eliminate it.
Austin Clements [Wed, 4 Nov 2015 00:47:07 +0000 (19:47 -0500)]
runtime: don't start idle mark workers when barriers are cleared
Currently, we don't start dedicated or fractional mark workers unless
the mark 1 or mark 2 barriers have been cleared. One intended
consequence of this is that no background workers run between the
forEachP that disposes all gcWork caches and the beginning of mark 2.
However, we (unintentionally) did not apply this restriction to idle
mark workers. As a result, these can start in the interim between mark
1 completion and mark 2 starting. This explains why it was necessary
to reset the root marking jobs using carefully ordered atomic writes
when setting up mark 2. It also means that, even though we definitely
enqueue work before starting mark 2, it may be drained by the time we
reset the mark 2 barrier. If this happens, currently the only thing
preventing the runtime from deadlocking is that the scheduler itself
also checks for mark completion and will signal mark 2 completion.
Were it not for the odd behavior of idle workers, this check in the
scheduler would not be necessary.
Clean all of this up and prepare to remove this check in the scheduler
by applying the same restriction to starting idle mark workers.
Austin Clements [Fri, 23 Oct 2015 19:55:03 +0000 (15:55 -0400)]
runtime: decentralize sweep termination and mark transition
This moves all of GC initialization, sweep termination, and the
transition to concurrent marking in to the off->mark transition
function. This means it's now handled on the goroutine that detected
the state exit condition.
As a result, malloc no longer needs to Gosched() at the beginning of
the GC cycle to prevent over-allocation while the GC is starting up
because it will now *help* the GC to start up. The Gosched hack is
still necessary during GC shutdown (this is easy to test by enabling
gctrace and hitting Ctrl-S to block the gctrace output).
At this point, the GC coordinator still handles later phases. This
requires a small tweak to how we start the GC coordinator. Currently,
starting the GC coordinator is best-effort and may fail if the
coordinator is about to park from the previous cycle but hasn't yet.
We fix this by replacing the park/ready to wake up the coordinator
with a semaphore. This is temporary since the coordinator will be
going away in a few commits.
This moves concurrent sweep termination from the coordinator to the
off->mark transition. This allows it to be performed by all Gs
attempting to start the GC.
Austin Clements [Fri, 23 Oct 2015 18:15:18 +0000 (14:15 -0400)]
runtime: beginning of decentralized off->mark transition
This begins the conversion of the centralized GC coordinator to a
decentralized state machine by introducing the internal API that
triggers the first state transition from _GCoff to _GCmark (or
_GCmarktermination).
This change introduces the transition lock, the off->mark transition
condition (which is very similar to shouldtriggergc()), and the
general structure of a state transition. Since we're doing this
conversion in stages, it then falls back to the GC coordinator to
actually execute the cycle. We'll start moving logic out of the GC
coordinator and in to transition functions next.
This fixes a minor bug in gcstoptheworld debug mode where passing the
heap trigger once could trigger multiple STW GCs.
Austin Clements [Sun, 25 Oct 2015 01:19:52 +0000 (21:19 -0400)]
runtime: move concurrent mark setup off system stack
For historical reasons we currently do a lot of the concurrent mark
setup on the system stack. In fact, at this point the one and only
thing that needs to happen on the system stack is the start-the-world.
Clean up this code by lifting everything other than the
start-the-world off the system stack.
The diff for this change looks large, but the only code change is to
narrow the systemstack call. Everything else is re-indentation.
Austin Clements [Fri, 23 Oct 2015 19:17:04 +0000 (15:17 -0400)]
runtime: lift state variables from func gc to var work
We're about to split func gc across several functions, so lift the
local variables it uses for tracking statistics and state across the
cycle into the global "work" variable.
Ian Lance Taylor [Thu, 5 Nov 2015 01:38:53 +0000 (17:38 -0800)]
cmd/go: change ar argument to rc
Put 'r' first because that is the command, and 'c' is the modifier.
Keep 'c' because it means to not warn when creating an archive.
Drop 'u' because it is unnecessary and fails on Arch Linux.
No test because this is only for gccgo (I tested it manually).
Fixes #12310.
Change-Id: Id740257fb1c347dfaa60f7d613af2897dae2c059
Reviewed-on: https://go-review.googlesource.com/16664
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
Keith Randall [Fri, 20 Mar 2015 21:12:05 +0000 (14:12 -0700)]
runtime: simplify buffered channels.
This change removes the retry mechanism we use for buffered channels.
Instead, any sender waking up a receiver or vice versa completes the
full protocol with its counterpart. This means the counterpart does
not need to relock the channel when it wakes up. (Currently
buffered channels need to relock on wakeup.)
For sends on a channel with waiting receivers, this change replaces
two copies (sender->queue, queue->receiver) with one (sender->receiver).
For receives on channels with a waiting sender, two copies are still required.
This change unifies to a large degree the algorithm for buffered
and unbuffered channels, simplifying the overall implementation.
Shenghou Ma [Thu, 5 Nov 2015 02:20:33 +0000 (21:20 -0500)]
crypto/x509: add /etc/ssl/certs to certificate directories
Fixes #12139.
Change-Id: Ied760ac37e2fc21ef951ae872136dc3bfd49bf9f
Reviewed-on: https://go-review.googlesource.com/16671 Reviewed-by: Ian Lance Taylor <iant@golang.org>
While here, enable getrandom on arm64 too (using the value found in
include/uapi/asm-generic/unistd.h, which seems to match up with other
GOARCH=arm64 syscall numbers).
Updates #10848.
Change-Id: I5ab36ccf6ee8d5cc6f0e1a61d09f0da7410288b9
Reviewed-on: https://go-review.googlesource.com/16662
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Mon, 26 Oct 2015 21:07:02 +0000 (17:07 -0400)]
runtime: make putfull start mark workers
Currently we depend on the good graces and timing of the scheduler to
get opportunities to start dedicated mark workers. In the worst case,
it may take 10ms to get dedicated mark workers going at the beginning
of mark 1 and mark 2 or after the amount of available work has dropped
and gone back up.
Instead of waiting for the regular preemption logic to get around to
us, make putfull enlist a random P if we're not already running enough
dedicated workers. This should improve performance stability of the
garbage collector and is likely to improve the overall performance
somewhat.
No overall effect on the go1 benchmarks. It speeds up the garbage
benchmark by 12%, which more than counters the performance loss from
the previous commit.
name old time/op new time/op delta
XBenchGarbage-12 6.32ms ± 4% 5.58ms ± 2% -11.68% (p=0.000 n=20+16)
Austin Clements [Mon, 26 Oct 2015 20:29:25 +0000 (16:29 -0400)]
runtime: eliminate getfull barrier from concurrent mark
Currently dedicated mark workers participate in the getfull barrier
during concurrent mark. However, the getfull barrier wasn't designed
for concurrent work and this causes no end of headaches.
In the concurrent setting, participants come and go. This makes mark
completion susceptible to live-lock: since dedicated workers are only
periodically polling for completion, it's possible for the program to
be in some transient worker each time one of the dedicated workers
wakes up to check if it can exit the getfull barrier. It also
complicates reasoning about the system because dedicated workers
participate directly in the getfull barrier, but transient workers
must instead use trygetfull because they have exit conditions that
aren't captured by getfull (e.g., fractional workers exit when
preempted). The complexity of implementing these exit conditions
contributed to #11677. Furthermore, the getfull barrier is inefficient
because we could be running user code instead of spinning on a P. In
effect, we're dedicating 25% of the CPU to marking even if that means
we have to spin to make that 25%. It also causes issues on Windows
because we can't actually sleep for 100µs (#8687).
Fix this by making dedicated workers no longer participate in the
getfull barrier. Instead, dedicated workers simply return to the
scheduler when they fail to get more work, regardless of what others
workers are doing, and the scheduler only starts new dedicated workers
if there's work available. Everything that needs to be handled by this
barrier is already handled by detection of mark completion.
This makes the system much more symmetric because all workers and
assists now use trygetfull during concurrent mark. It also loosens the
25% CPU target so that we can give some of that 25% back to user code
if there isn't enough work to keep the mark worker busy. And it
eliminates the problematic 100µs sleep on Windows during concurrent
mark (though not during mark termination).
The downside of this is that if we hit a bottleneck in the heap graph
that then expands back out, the system may shut down dedicated workers
and take a while to start them back up. We'll address this in the next
commit.
Updates #12041 and #8687.
No effect on the go1 benchmarks. This slows down the garbage benchmark
by 9%, but we'll more than make it up in the next commit.
name old time/op new time/op delta
XBenchGarbage-12 5.80ms ± 2% 6.32ms ± 4% +9.03% (p=0.000 n=20+20)
Change-Id: I65100a9ba005a8b5cf97940798918672ea9dd09b
Reviewed-on: https://go-review.googlesource.com/16297 Reviewed-by: Rick Hudson <rlh@golang.org>