Now that sweeping and span marking use the sweep list, there's no need
for the work.spans snapshot of the allspans list. This change
eliminates the few remaining uses of it, which are either dead code or
can use allspans directly, and removes work.spans and its support
functions.

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

Currently markrootSpans iterates over all spans ever allocated to find
the in-use spans. Since we now have a list of in-use spans, change it
to iterate over that instead.

This, combined with the previous change, fixes #9265. Before these two
changes, blowing up the heap to 8GB and then shrinking it to a 0MB
live set caused the small-heap portion of the test to run 60x slower
than without the initial blowup. With these two changes, the time is
indistinguishable.

No significant effect on other benchmarks.

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

Currently sweeping walks the list of all spans, which means the work
in sweeping is proportional to the maximum number of spans ever used.
If the heap was once large but is now small, this causes an
amortization failure: on a small heap, GCs happen frequently, but a
full sweep still has to happen in each GC cycle, which means we spent
a lot of time in sweeping.

Fix this by creating a separate list consisting of just the in-use
spans to be swept, so sweeping is proportional to the number of in-use
spans (which is proportional to the live heap). Specifically, we
create two lists: a list of unswept in-use spans and a list of swept
in-use spans. At the start of the sweep cycle, the swept list becomes
the unswept list and the new swept list is empty. Allocating a new
in-use span adds it to the swept list. Sweeping moves spans from the
unswept list to the swept list.

This fixes the amortization problem because a shrinking heap moves
spans off the unswept list without adding them to the swept list,
reducing the time required by the next sweep cycle.

Updates #9265. This fix eliminates almost all of the time spent in
sweepone; however, markrootSpans has essentially the same bug, so now
the test program from this issue spends all of its time in
markrootSpans.

No significant effect on other benchmarks.

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

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

Currently we set the len and cap of h.spans to the full reserved
region of the address space and track the actual mapped region
separately in h.spans_mapped. Since we have both the len and cap at
our disposal, change things so len(h.spans) tracks how much of the
spans array is mapped and eliminate h.spans_mapped. This simplifies
mheap and means we'll get nice "index out of bounds" exceptions if we
do try to go off the end of the spans rather than a SIGSEGV.

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

Like h_allspans and mheap_.allspans, these were two ways of referring
to the spans array from when the runtime was split between C and Go.
Clean this up by making mheap_.spans a slice and eliminating h_spans.

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

This was necessary in the C days when allspans was an mspan**, but now
that allspans is a Go slice, this is redundant with len(allspans) and
we can use range loops over allspans.

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

These are two ways to refer to the allspans array that hark back to
when the runtime was split between C and Go. Clean this up by making
mheap_.allspans a slice and eliminating h_allspans.

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

Change-Id: I3c784986755cfbbe1b8eb8da4d64227bd109a3b0
Reviewed-on: https://go-review.googlesource.com/27203
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

Generated from go vet.

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

Generated from go vet.

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

When the compiler insert write barriers, the frontend makes
conservative decisions at an early stage. This may have false
positives which result in write barriers for stack writes.

A new phase, writebarrier, is added to the SSA backend, to delay
the decision and eliminate false positives. The frontend still
makes conservative decisions. When building SSA, instead of
emitting runtime calls directly, it emits WB ops (StoreWB,
MoveWB, etc.), which will be expanded to branches and runtime
calls in writebarrier phase. Writes to static locations on stack
are detected and write barriers are removed.

All write barriers of stack writes found by the script from
issue #17330 are eliminated (except two false positives).

Fixes #17330.

Change-Id: I9bd66333da9d0ceb64dcaa3c6f33502798d1a0f8
Reviewed-on: https://go-review.googlesource.com/31131Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>

The runtime traceback code assumes non-empty frame has link
link register saved on LR architectures. Make sure it is so in
the assember.

Also make sure that LR is stored before update SP, so the traceback
code will not see a half-updated stack frame if a signal comes
during the execution of function prologue.

Fixes #17381.

Change-Id: I668b04501999b7f9b080275a2d1f8a57029cbbb3
Reviewed-on: https://go-review.googlesource.com/31760Reviewed-by: Michael Munday <munday@ca.ibm.com>

This interface will be implemented by golang.org/x/net/http2 in
https://go-review.googlesource.com/c/29439/.

Updates golang/go#13443

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

Update the ppc64x disassembly code for use by objdump
from golang.org/x/arch/ppc64/ppc64asm commit fcea5ea.
Enable the objdump testcase for external linking on ppc64le
make a minor fix to the expected output.

Fixes #17447

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

Fixes #17148.

Change-Id: I4c66aa0733c249ee6019d1c4e802a7e30457d4b6
Reviewed-on: https://go-review.googlesource.com/32030
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

The Dragonfly libc returns a non-zero value for malloc(-1).

Fixes #17585.

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

Reduces the size of LSym struct.

On 32bit: before 84  after 76
On 64bit: before 136 after 128

name       old time/op     new time/op     delta
Template       182ms ± 3%      182ms ± 3%    ~           (p=0.607 n=19+20)
Unicode       93.5ms ± 4%     94.2ms ± 3%    ~           (p=0.141 n=20+19)
GoTypes        608ms ± 1%      605ms ± 2%    ~           (p=0.056 n=20+20)

name       old user-ns/op  new user-ns/op  delta
Template        249M ± 7%       249M ± 4%    ~           (p=0.605 n=18+19)
Unicode         149M ±14%       151M ± 5%    ~           (p=0.724 n=20+17)
GoTypes         855M ± 4%       853M ± 3%    ~           (p=0.537 n=19+19)

name       old alloc/op    new alloc/op    delta
Template      40.3MB ± 0%     40.3MB ± 0%  -0.11%        (p=0.000 n=19+20)
Unicode       33.8MB ± 0%     33.8MB ± 0%  -0.08%        (p=0.000 n=20+20)
GoTypes        119MB ± 0%      119MB ± 0%  -0.10%        (p=0.000 n=19+20)

name       old allocs/op   new allocs/op   delta
Template        383k ± 0%       383k ± 0%    ~           (p=0.703 n=20+20)
Unicode         317k ± 0%       317k ± 0%    ~           (p=0.982 n=19+18)
GoTypes        1.14M ± 0%      1.14M ± 0%    ~           (p=0.086 n=20+20)

Change-Id: Id6ba0db3ecc4503a4e9af3ed0d5884d4366e8bf9
Reviewed-on: https://go-review.googlesource.com/31870Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Shahar Kohanim <skohanim@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

For historical reasons, the go/doc package does not include
the methods within an interface as part of the documented
methods for that type. Thus,

	go doc ast.Node.Pos

gives an incorrect and confusing error message:

	doc: no method Node.Pos in package go/ast

This CL does some dirty work to dig down to the methods
so interface methods now present their documentation:

% go doc ast.node.pos
func Pos() token.Pos  // position of first character belonging to the node
%

It must largely sidestep the doc package to do this, which
is a shame. Perhaps things will improve there one day.

The change does not handle embeddings, and in principle the
same approach could be done for struct fields, but that is also
not here yet. But this CL fixes the thing that was bugging me.

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

CL 31330 added more envvars to "go env".
This CL brings them to "go bug" as well.

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

Instead of generating typelink symbols in the compiler
mark types that should have typelinks with a flag.
The linker detects this flag and adds the marked types
to the typelink table.

name            old s/op    new s/op    delta
LinkCmdCompile   0.27 ± 6%   0.25 ± 6%  -6.93%    (p=0.000 n=97+98)
LinkCmdGo        0.30 ± 5%   0.29 ±10%  -4.22%    (p=0.000 n=97+99)

name            old MaxRSS  new MaxRSS  delta
LinkCmdCompile   112k ± 3%   106k ± 2%  -4.85%  (p=0.000 n=100+100)
LinkCmdGo        107k ± 3%   103k ± 3%  -3.00%  (p=0.000 n=100+100)

Change-Id: Ic95dd4b0101e90c1fa262c9c6c03a2028d6b3623
Reviewed-on: https://go-review.googlesource.com/31772
Run-TryBot: Shahar Kohanim <skohanim@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

The condition to determine if any further iterations are needed is
evaluated to false in case it encounters a NaN. Instead, flip the
condition to keep looping until the factor is greater than the machine
roundoff error.

Updates #17577

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

In sinit.go, gdata can already handle strings and complex, so no
reason to handle them separately.

In obj.go, inline gdatastring and gdatacomplex into gdata, since it's
the only caller. Allows extracting out the common Linksym calls.

Passes toolstash -cmp.

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

Fixes #17584.

Change-Id: I3af31cc1f2e9c906f3b73e77f3b092624ba78fbe
Reviewed-on: https://go-review.googlesource.com/31939
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

Bug 15141 was apparently fixed by some other change to the
compiler (this is plausible, it was a weird bug dependent
on a particular way of returning a large named array result),
add the test to ensure that it stays fixed.

Updates #15141.

Change-Id: I3d6937556413fab1af31c5a1940e6931563ce2f3
Reviewed-on: https://go-review.googlesource.com/31972
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

No functional changes.

Change-Id: I0842b2560f4296abfc453410fdd79514132cab83
Reviewed-on: https://go-review.googlesource.com/31935
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

It no longer exists as of CL 31010.

Change-Id: Idd61f392544cad8b3f3f8d984dc5c953b473e2e5
Reviewed-on: https://go-review.googlesource.com/31934
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Some original shift opcodes for ppc64x expected an operand to be
a mask instead of a shift count, preventing some valid shift counts
from being written.

This adds new opcodes for shifts where needed, using mnemonics that
match the ppc64 asm and allowing the assembler to accept the full set
of valid shift counts.

Fixes #15016

Change-Id: Id573489f852038d06def279c13fd0523736878a7
Reviewed-on: https://go-review.googlesource.com/31853
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: David Chase <drchase@google.com>

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

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

While we're here, use test[%d] in place of #%d.

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

Introduced in CLs 29380 and 30011.

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

Fixes #16811.

Change-Id: I7d018015f691838482ccf845d621209b96935ba4
Reviewed-on: https://go-review.googlesource.com/31657
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>

These are emulated by the assembler and we don't need them.

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

Implements the following intrinsics on s390x:
 - AtomicAdd{32,64}
 - AtomicCompareAndSwap{32,64}
 - AtomicExchange{32,64}
 - AtomicLoad{32,64,Ptr}
 - AtomicStore{32,64,PtrNoWB}

I haven't added rules for And8 or Or8 yet.

Change-Id: I647af023a8e513718e90e98a60191e7af6167314
Reviewed-on: https://go-review.googlesource.com/31614
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Apply the optimizations added to color conversion functions in
https://go-review.googlesource.com/#/c/21910/ to the RGBA methods.

YCbCrToRGBA/0-4      6.32ns ± 3%  6.58ns ± 2%   +4.15%  (p=0.000 n=20+19)
YCbCrToRGBA/128-4    8.02ns ± 2%  5.89ns ± 2%  -26.57%  (p=0.000 n=20+19)
YCbCrToRGBA/255-4    8.06ns ± 2%  6.59ns ± 3%  -18.18%  (p=0.000 n=20+20)
NYCbCrAToRGBA/0-4    8.71ns ± 2%  8.78ns ± 2%   +0.86%  (p=0.036 n=19+20)
NYCbCrAToRGBA/128-4  10.3ns ± 4%   7.9ns ± 2%  -23.44%  (p=0.000 n=20+20)
NYCbCrAToRGBA/255-4  9.64ns ± 2%  8.79ns ± 3%   -8.80%  (p=0.000 n=20+20)

Fixes: #15260

Change-Id: I225efdf74603e8d2b4f063054f7baee7a5029de6
Reviewed-on: https://go-review.googlesource.com/31773
Run-TryBot: Martin Möhrmann <martisch@uos.de>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>

name       old s/op    new s/op    delta
LinkCmdGo   0.29 ± 5%   0.29 ± 8%  -2.60%   (p=0.000 n=97+98)

name       old MaxRSS  new MaxRSS  delta
LinkCmdGo   106k ± 4%   105k ± 3%  -1.00%  (p=0.000 n=100+99)

Change-Id: I75a1c3b24ea711a15a5d2eae026b70b97ee7bad4
Reviewed-on: https://go-review.googlesource.com/31030
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>

Before go supported buildmode=shared ·f symbols used to be defined
only when they were used. In order to solve #11480 the strategy
was changed to have these symbols defined on declaration which is
less efficient and generates many unneeded symbols.
With this change the best strategy is chosen for each situation,
improving static linking time:

name            old s/op    new s/op    delta
LinkCmdCompile   0.27 ± 5%   0.25 ± 6%  -8.22%   (p=0.000 n=98+96)
LinkCmdGo        0.30 ± 6%   0.29 ± 8%  -5.03%   (p=0.000 n=95+99)

name            old MaxRSS  new MaxRSS  delta
LinkCmdCompile   107k ± 2%    98k ± 3%  -8.32%  (p=0.000 n=99+100)
LinkCmdGo        106k ± 3%   104k ± 3%  -1.94%  (p=0.000 n=99+100)

Change-Id: I965eeee30541e724fd363804adcd6fda10f965a4
Reviewed-on: https://go-review.googlesource.com/31031Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>

In general, these functions cannot behave correctly when given a
hostname, because a hostname may represent multiple IP addresses, and
first(isIPv4) chooses at most one.

Updates #9334

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

Looking at the kernel sources, I don't see how this is possible.
But obviously it is. Just try again.

Fixes #17161.

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