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).

Hence, replace this allocation with a throw.

Updates #10600.

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

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.

Updates #10600.

Change-Id: I0a63eecec1992e195449f414ed47653f66318d0e
Reviewed-on: https://go-review.googlesource.com/16814
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

This replaces *traceStack with traceStackPtr, much like the preceding
commit.

Updates #10600.

Change-Id: Ifadc35eb37a405ae877f9740151fb31a0ca1d08f
Reviewed-on: https://go-review.googlesource.com/16813
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

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.

Updates #10600.

Change-Id: I52b992d36d1b634ebd855c8cde27947ec14f59ba
Reviewed-on: https://go-review.googlesource.com/16812
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

Mention shallow clones.

Fixes #13204

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

Commit 7407d8e5 was rebased over the switch to runtime/internal/atomic
and introduced a call to xadd64, which no longer exists. Fix that
call.

Change-Id: I99c93469794c16504ae4a8ffe3066ac382c66a3a
Reviewed-on: https://go-review.googlesource.com/16816Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

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/16515Reviewed-by: Rick Hudson <rlh@golang.org>

Currently go get will clone the full history of git repos.
We can improve the download waiting time/size by passing depth argument.

The docs about shallow clones and the --depth argument are here:
https://git-scm.com/docs/git-clone
https://git-scm.com/docs/git-pull

Fixes #13078

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

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/16660Reviewed-by: David Crawshaw <crawshaw@golang.org>

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/16611Reviewed-by: David Crawshaw <crawshaw@golang.org>

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/16511Reviewed-by: Rick Hudson <rlh@golang.org>

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.

Fixes #11465.

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

When using gccgo it's OK if a pointer passed to C remains on the stack.
Gccgo does not have the clear distinction between C and Go stacks.

Change-Id: I3af9dd6fe078214ab16d9d8dad2d206608d7891d
Reviewed-on: https://go-review.googlesource.com/16774
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

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.

Update #12416.

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

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>

(This relands commit a4dcc692.)

https://tools.ietf.org/html/rfc6066#section-3 states:

  “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.

Fixes #13111.

Change-Id: I6e544a78a01388f8fe98150589d073b917087f75
Reviewed-on: https://go-review.googlesource.com/16776
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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>

The compiler should not usually call Fconv with an infinity, but if
it does, Fconv will end in an endless loop. Test for infinities early.

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

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>

And enable PIE in cmd/go because that's all it seems to take.

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

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

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.

Change-Id: I6698c8e3cf3834f55ce5824059f44d00dc8e3c2f
Reviewed-on: https://go-review.googlesource.com/14204
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

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.

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

Fixes #13135

Change-Id: I45666f32cd91102211bf01a306edcb10deb65187
Reviewed-on: https://go-review.googlesource.com/16680
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

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/16752Reviewed-by: Ian Lance Taylor <iant@golang.org>

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

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

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

Fixes #12301

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

Change-Id: I1da1d718609eb6a7b78d29b173ec780bde22c687
Reviewed-on: https://go-review.googlesource.com/16422Reviewed-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>

This reverts commit a4dcc692.

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

https://tools.ietf.org/html/rfc6066#section-3 states:

  “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.

Fixes #13111.

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

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

Reduces size of godoc .text section by about 75k (or 1.4%).

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

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/16483Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

In https://go-review.googlesource.com/#/c/16554/ y.go was modified
manually, but go.y (which is the source for y.go) was not changed.

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

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/16740Reviewed-by: Ian Lance Taylor <iant@golang.org>

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

Also change a -v print, for consistency.

Fixes #12913

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

Change-Id: I0d0abbb9503c3a3c35d846fc0379836b2c483dea
Reviewed-on: https://go-review.googlesource.com/15962Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>