LGTM=dave
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/72260045

LGTM=dave
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/72240045

If we report a leak, make sure we've waited long enough to be sure.
The new sleep regimen waits 1.05 seconds before failing; the old
one waited 0.005 seconds.

(The single linux/amd64 failure in this test feels more like a
timing problem than a leak. I don't want to spend time on it unless
we're sure.)

LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/72630043

We provide amd64p32 implementations for md5 and sha1 so we need to exclude amd64p32 from the generic implementations in those packages.

Fixes build once CL 72360044 lands.

LGTM=agl, remyoudompheng
R=rsc, bradfitz, agl, remyoudompheng
CC=golang-codereviews
https://golang.org/cl/72460043

This produces about a 2.3x speedup for patterns
that can be handled this way.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/13345046

Fixes build on windows/386 and plan9/386.
Fixes #7487.

LGTM=mattn.jp, dvyukov, rsc
R=golang-codereviews, mattn.jp, dvyukov, 0intro, rsc
CC=golang-codereviews
https://golang.org/cl/72360043

This fixes the following amd64p32 issue:
    pkg/time/format.go:724: internal compiler error: twobitwalktype1: invalid initial alignment, Time

caused by the pointer zone ending on a 32-bit-aligned boundary.

LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/72270046

This code being buggy is the only explanation I can come up
with for issue 7325. It's probably not, but the only alternative
is a Windows kernel bug. Comment this out to see what breaks
or gets fixed.

Update #7325

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/72590044

From the trace it appears that stackalloc is being
called with 0x1800 which is 6k = 4k + (StackSystem=2k).
Make StackSystem 4k too, to make stackalloc happy.
It's already 4k on windows/amd64.

TBR=khr
CC=golang-codereviews
https://golang.org/cl/72600043

It was using MOVL to pass a 64-bit argument
(concatenated framesize and argsize) to morestack11.

LGTM=dave, rsc
R=dave, rsc, iant
CC=golang-codereviews
https://golang.org/cl/72360044

There are at least 3 bugs:
1. g->stacksize accounting is broken during copystack/shrinkstack
2. stktop->free is not properly maintained during copystack/shrinkstack
3. stktop->free logic is broken:
        we can have stktop->free==FixedStack,
        and we will free it into stack cache,
        but it actually comes from heap as the result of non-copying segment shrink
This shows as at least spurious races on race builders (maybe something else as well I don't know).

The idea behind the refactoring is to consolidate stacksize and
segment origin logic in stackalloc/stackfree.

Fixes #7490.

LGTM=rsc, khr
R=golang-codereviews, rsc, khr
CC=golang-codereviews
https://golang.org/cl/72440043

Recursive panics leave dangling Panic structs in g->panic stack.
At best it leads to a Defer leak and incorrect output on a subsequent panic.
At worst it arbitrary corrupts heap.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/72480043

One reason the sync.Pool finalizer test can fail is that
this function's ef1 contains uninitialized data that just
happens to point at some of the old pool. I've seen this cause
retention of a single pool cache line (32 elements) on arm.

Really we need liveness information for C functions, but
for now we can be more careful about data in long-lived
C functions that block.

LGTM=bradfitz, dvyukov
R=golang-codereviews, bradfitz, dvyukov
CC=golang-codereviews, iant, khr
https://golang.org/cl/72490043

Replaces CL 70000043.

Switch to the amd64p32 linker model if we are building under nacl/amd64p32.

No need to introduce linkarchinit() as 6a contains its own main() function.

LGTM=rsc
R=rsc, minux.ma
CC=golang-codereviews
https://golang.org/cl/72020043

Replaces CL 70000043.

Introduce linkarchinit() from cmd/ld.

For cmd/6g, switch to the amd64p32 linker model if we are building under nacl/amd64p32.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/71330045

Just commentary describing existing behavior, no code changes.

Fixes #7033.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/71860043

Documenting existing behavior; new commentary only.
Fixes #7105.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/68840044

This documents the status quo for most implementations,
with one exception: gc generates a run-time error for
constant but out-of-range indices when slicing a constant
string. See issue 7200 for a detailed discussion.

LGTM=r
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/72160044

Instead, split the underlying storage in half and
free just half of it.

Shrinking without copying lets us reclaim storage used
by a previously profligate Go routine that has now blocked
inside some C code.

To shrink in place, we need all stacks to be a power of 2 in size.

LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/69580044

This is a test case for CL 34680044.

Fixes #6333.

LGTM=bradfitz
R=golang-codereviews, bradfitz, minux.ma
CC=golang-codereviews
https://golang.org/cl/71230049

Two memory allocator bug fixes.

- efence is not maintaining the proper heap metadata
  to make eventual memory reuse safe, so use SysFault.

- now that our heap PageSize is 8k but most hardware
  uses 4k pages, SysAlloc and SysReserve results must be
  explicitly aligned. Do that in a few more call sites and
  document this fact in malloc.h.

Fixes #7448.

LGTM=iant
R=golang-codereviews, josharian, iant
CC=dvyukov, golang-codereviews
https://golang.org/cl/71750048

cmd/5c/txt.c was missing from CL 72010043.

LGTM=bradfitz
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/72220043

Replaces CL 70000043.

Introduce linkarchinit() from cmd/ld.

For cmd/6c, switch to the amd64p32 linker model if we are building under nacl/amd64p32.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/72010043

I've just needed the G status on fault to debug runtime bug.
For some reason we print everything except header here.
Make it more informative and consistent.

R=rsc
CC=golang-codereviews
https://golang.org/cl/67870056

warning: pkg/runtime/mgc0.c:2352 format mismatch p UVLONG, arg 2
warning: pkg/runtime/mgc0.c:2352 format mismatch p UVLONG, arg 3

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/71950044

Implement custom assembly thunks for hot race calls (memory accesses and function entry/exit).
The thunks extract caller pc, verify that the address is in heap or global and switch to g0 stack.

Before:
ok  	regexp	3.692s
ok  	compress/bzip2	9.461s
ok  	encoding/json	6.380s
After:
ok  	regexp	2.229s (-40%)
ok  	compress/bzip2	4.703s (-50%)
ok  	encoding/json	3.629s (-43%)

For comparison, normal non-race build:
ok  	regexp	0.348s
ok  	compress/bzip2	0.304s
ok  	encoding/json	0.661s
Race build:
ok  	regexp	2.229s (+540%)
ok  	compress/bzip2	4.703s (+1447%)
ok  	encoding/json	3.629s (+449%)

Also removes some race-related special cases from cgocall and scheduler.
In long-term it will allow to remove cyclic runtime/race dependency on cmd/cgo.

Fixes #4249.
Fixes #7460.
Update #6508
Update #6688

R=iant, rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/55100044

Fixes #7196

LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews, iant
https://golang.org/cl/69970052

NOT A LANGUAGE CHANGE.

Fixes #7073.

LGTM=r
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/68840045

LGTM=khr
R=khr
CC=golang-codereviews, rsc
https://golang.org/cl/69870054

It was caused by mstats.heap_alloc skew.
Fixes #7430.

LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/69870055

Currently it fails on second and subsequent runs (when using -cpu=1,2,4) as:
--- FAIL: TestUseProxy-4 (0.00 seconds)
proxy_test.go:109: useProxy(barbaz.net) = true, want false
proxy_test.go:109: useProxy(foobar.com) = true, want false
proxy_test.go:109: useProxy(www.foobar.com) = true, want false

LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/71940044

Fixes #7459.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/71060044

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/71950043

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/71940043

Tested GOARM=6 on Raspberry Pi, and I found only a few tests that
use sub-normal numbers fails. I have a patch to NetBSD kernel pending
that fixes this issue (NetBSD kernel doesn't allow us to disable the
Flush-to-Zero feature).

LGTM=jsing
R=golang-codereviews, jsing
CC=golang-codereviews
https://golang.org/cl/70730043

LGTM=jsing
R=golang-codereviews, jsing
CC=golang-codereviews
https://golang.org/cl/70720043

The underlying type of the predeclared type error is not itself,
but the interface it is defined as.

Fixes #7444.

LGTM=r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/71790044

Fixes #7449.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/71610044

To be enabled by https://golang.org/cl/71230045/

Update #7442

LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/69860056

I missed this one in codereview.appspot.com/70010050
Same thing, but different test.

Fixes windows-amd64-race and likely other Windows
machines failing like:
http://build.golang.org/log/0382bf0048bf5835a51a8a902df5c6fc73cd7ff5

LGTM=adg
R=rsc, adg
CC=golang-codereviews
https://golang.org/cl/71770043