This functionality might be used in environments
where programs are limited to a single thread,
to simulate a select-driven network server.  It is
not exposed via the standard runtime API.

R=r, r2
CC=golang-dev
https://golang.org/cl/4254041

to move some variables from the stack to the heap.

Sorted benchmark runs on my 2007-era Mac Mini (GOARCH=amd64, GOOS=linux):

Before:
lzw.BenchmarkDecoder        2000        878176 ns/op
lzw.BenchmarkDecoder        2000        878415 ns/op
lzw.BenchmarkDecoder        2000        880352 ns/op
lzw.BenchmarkDecoder        2000        898445 ns/op
lzw.BenchmarkDecoder        2000        901728 ns/op

After:
lzw.BenchmarkDecoder        2000        859065 ns/op
lzw.BenchmarkDecoder        2000        859402 ns/op
lzw.BenchmarkDecoder        2000        860035 ns/op
lzw.BenchmarkDecoder        2000        860555 ns/op
lzw.BenchmarkDecoder        2000        861109 ns/op

The ratio of before/after median times is 1.024.

The runtime.MemStats.Mallocs delta per loop drops from 109 to 104.

R=r, r2, dfc
CC=golang-dev
https://golang.org/cl/4253043

on each loop iteration, yielding a 20x performance improvement.

R=rsc, r2
CC=golang-dev
https://golang.org/cl/4240044

R=agl, agl1
CC=golang-dev
https://golang.org/cl/4255041

again.
CL 4222043 missed this case.

R=brainman, r, r2
CC=golang-dev
https://golang.org/cl/4235043

go/doc wants to see text after BUG(uid): on the same line
in order to treat it as an official bug comment.

R=gri
CC=golang-dev
https://golang.org/cl/4250043

Using the kernel-supplied compare-and-swap code
on linux/arm means that runtime doesn't have to care
whether this is GOARM=5 or GOARM=6 anymore.

Fixes #1494.

R=r, r2
CC=golang-dev
https://golang.org/cl/4245043

Remove references to custom assembly routines.

R=r, r2
CC=golang-dev
https://golang.org/cl/4241043

Fixes #170.

R=gri, iant, r, r2
CC=golang-dev
https://golang.org/cl/4241041

R=r, r2, gri
CC=ehog.hedge, golang-dev
https://golang.org/cl/4240043

Before this fix, types such as
        type T map[string]T
caused infinite recursion in the gob implementation.
Now they just work.

Fixes #1518.

R=rsc
CC=golang-dev
https://golang.org/cl/4230045

R=ken2
CC=golang-dev
https://golang.org/cl/4240041

R=ken2
CC=golang-dev
https://golang.org/cl/4239041

Also: renamed fixedbugs/bug322.go to fixedbugs/bug323.go
because we already have a bugs/bug322.go and bug322.dir.

R=rsc
CC=golang-dev
https://golang.org/cl/4219044

R=rsc
CC=golang-dev
https://golang.org/cl/4231045

R=r, rsc
CC=golang-dev
https://golang.org/cl/4213044

R=bradfitzgo
CC=golang-dev
https://golang.org/cl/3989052

When providing addition file systems to godoc via -path, the
path names may be symbolic links. Follow them.

Also: better logging of error and special conditions.

R=r, dsymonds, r2
CC=golang-dev
https://golang.org/cl/4217045

R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/4223049

R=rsc, nigeltao_gnome
CC=golang-dev
https://golang.org/cl/4209043

The pointer will eventually let us find *T given T.
This CL just makes room for it, always storing a zero.

R=r, r2
CC=golang-dev
https://golang.org/cl/4221046

In CL 4188061 I changed malg to allocate the requested
number of bytes n, not n+StackGuard, so that the
allocations would use rounder numbers.

The allocation of the signal stack asks for 32k and
then used g->stackguard as the base, but g->stackguard
is StackGuard bytes above the base.  Previously, asking
for 32k meant getting 32k+StackGuard bytes, so using
g->stackguard as the base was safe.  Now, the actual base
must be computed, so that the signal handler does not
run StackGuard bytes past the top of the stack.

Was causing flakiness mainly in programs that use the
network, because they sometimes write to closed network
connections, causing SIGPIPEs.  Was also causing problems
in the doc/progs test.

Also fix Makefile so that changes to stack.h trigger rebuild.

R=bradfitzgo, r, r2
CC=golang-dev
https://golang.org/cl/4230044

A reference to the address of weak.foo resolves at link time
to the address of the symbol foo if foo would end up in the
binary anyway, or to zero if foo would not be in the binary.

For example:

        int xxx = 1;
        int yyy = 2;
        int weak·xxx;
        int weak·yyy;

        void main·main(void) {
                runtime·printf("%p %p %p\n", &xxx, &weak·xxx, &weak·yyy);
        }

prints the same non-nil address twice, then 0 (because yyy is not
referenced so it was dropped from the binary).

This will be used by the reflection tables.

R=iant
CC=golang-dev
https://golang.org/cl/4223044

Issue 1547 is fixed.

R=bradfitzgo, r
CC=golang-dev
https://golang.org/cl/4209045

If the filename was absolute, writeFileAtomically
used the wrong filename for ioutil.TempFile leading
to non-existent directories and the TempFile would
fail.

R=r, r2
CC=golang-dev
https://golang.org/cl/4224043

R=r, r2
CC=golang-dev
https://golang.org/cl/4230042

when we hit a newline during *scanln routines.

Fixes #1490.

R=rsc
CC=golang-dev
https://golang.org/cl/4209042

Fixes #1516.

R=rsc, mattn
CC=golang-dev
https://golang.org/cl/4214041

R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/4217042

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4210041

R=adg, bradfitzwork
CC=golang-dev
https://golang.org/cl/4229042

R=r, r2
CC=golang-dev
https://golang.org/cl/4226043

Avoids deadlocks like the one below, in which a stack split happened
in order to call lock(&stacks), but then the stack unsplit cannot run
because stacks is now locked.

The only code calling stackalloc that wasn't on a scheduler
stack already was malg, which creates a new goroutine.

runtime.futex+0x23 /home/rsc/g/go/src/pkg/runtime/linux/amd64/sys.s:139
       runtime.futex()
futexsleep+0x50 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:51
       futexsleep(0x5b0188, 0x300000003, 0x100020000, 0x4159e2)
futexlock+0x85 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:119
       futexlock(0x5b0188, 0x5b0188)
runtime.lock+0x56 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:158
       runtime.lock(0x5b0188, 0x7f0d27b4a000)
runtime.stackfree+0x4d /home/rsc/g/go/src/pkg/runtime/malloc.goc:336
       runtime.stackfree(0x7f0d27b4a000, 0x1000, 0x8, 0x7fff37e1e218)
runtime.oldstack+0xa6 /home/rsc/g/go/src/pkg/runtime/proc.c:705
       runtime.oldstack()
runtime.lessstack+0x22 /home/rsc/g/go/src/pkg/runtime/amd64/asm.s:224
       runtime.lessstack()
----- lessstack called from goroutine 2 -----
runtime.lock+0x56 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:158
       runtime.lock(0x5b0188, 0x40a5e2)
runtime.stackalloc+0x55 /home/rsc/g/go/src/pkg/runtime/malloc.c:316
       runtime.stackalloc(0x1000, 0x4055b0)
runtime.malg+0x3d /home/rsc/g/go/src/pkg/runtime/proc.c:803
       runtime.malg(0x1000, 0x40add9)
runtime.newproc1+0x12b /home/rsc/g/go/src/pkg/runtime/proc.c:854
       runtime.newproc1(0xf840027440, 0x7f0d27b49230, 0x0, 0x49f238, 0x40, ...)
runtime.newproc+0x2f /home/rsc/g/go/src/pkg/runtime/proc.c:831
       runtime.newproc(0x0, 0xf840027440, 0xf800000010, 0x44b059)
...

R=r, r2
CC=golang-dev
https://golang.org/cl/4216045

A terminal panic (one that prints a stack trace and exits)
has been calling runtime.breakpoint before calling exit,
so that if running under a debugger, the debugger can
take control.  When not running under a debugger, though,
this causes an additional SIGTRAP on Unix and pop-up
dialogs on Windows.

Support for debugging Go programs has gotten good
enough that we can rely on the debugger to set its own
breakpoint on runtime.exit if it wants to look around.

R=r, r2
CC=golang-dev
https://golang.org/cl/4222043

Much yet to come, but this is a safe first step, introducing
an in-the-future configurable Client object (where policy for
cookies, auth, redirects will live) as well as introducing a
ClientTransport interface for sending requests.

The CL intentionally ignores everything around the creation
and configuration of Clients and merely ports/wraps the old
interfaces to/around Client/ClientTransport.

R=rsc, dsymonds, nigeltao, bradfitzwork
CC=golang-dev
https://golang.org/cl/4182086

The existing code assumed that signals only arrived
while executing on the goroutine stack (g == m->curg),
not while executing on the scheduler stack (g == m->g0).

Most of the signal handling trampolines correctly saved
and restored g already, but the sighandler C code did not
have access to it.

Some rewriting of assembly to make the various
implementations as similar as possible.

Will need to change Windows too but I don't
understand how sigtramp gets called there.

R=r
CC=golang-dev
https://golang.org/cl/4203042

With this change, a panic trace due to a signal arriving while
running on the scheduler stack during a lessstack
(a stack unsplit) will trace through the lessstack to show
the state of the goroutine that was unsplitting its stack.

R=r
CC=golang-dev
https://golang.org/cl/4206042

same as in issue below, never fixed on ARM

changeset:   5498:3fa1372ca694
user:        Ken Thompson <ken@golang.org>
date:        Thu May 20 17:31:28 2010 -0700

description:
fix issue 798
cannot allocate an audomatic temp
while real registers are allocated.
there is a chance that the automatic
will be allocated to one of the
allocated registers. the fix is to
not registerize such variables.

R=rsc
CC=golang-dev
https://golang.org/cl/1202042

R=ken2
CC=golang-dev
https://golang.org/cl/4226042

R=rsc
CC=golang-dev
https://golang.org/cl/4220044

There are further changes required for things like
recursive map types.  Recursive struct types work
but the mechanism needs generalization.  The
case handled in this CL is pathological since it
cannot be represented at all by gob, so it should
be handled separately. (Prior to this CL, encode
would recur forever.)

R=rsc
CC=golang-dev
https://golang.org/cl/4206041