Current results on 2 core darwin/amd64:
BenchmarkGoroutineChain		351 ns/op
BenchmarkGoroutineChain-2	3840 ns/op
BenchmarkGoroutineChain-4	4040 ns/op
BenchmarkConcGoroutineChain	350 ns/op
BenchmarkConcGoroutineChain-2	875 ns/op
BenchmarkConcGoroutineChain-4	2027 ns/op

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

Fixes #3763.

R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6333066

I missed the API change in the last FreeBSD CL, but the tool caught it.

TBR=bradfitz
CC=golang-dev
https://golang.org/cl/6331063

Fixes #3630.

R=rsc
CC=bradfitz, dsymonds, golang-dev, rodrigo.moraes
https://golang.org/cl/6210067

R=golang-dev, rsc, bradfitz, devon.odell
CC=golang-dev
https://golang.org/cl/6221054

Guess I was wrong about being done for the day.

R=golang-dev, r
CC=golang-dev, unpantsu
https://golang.org/cl/6325060

Fixes #3752.

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

arm soft div and mod performance plays an important part
in runtime performance.

The currently implementation is very stable, but we believe
we can best it. This benchmark provides a reference point.

linux/arm omap4 pandaboard

BenchmarkUint32Div7     10000000               298 ns/op
BenchmarkUint32Div37    10000000               298 ns/op
BenchmarkUint32Div123   10000000               298 ns/op
BenchmarkUint32Div763   10000000               298 ns/op
BenchmarkUint32Div1247  10000000               299 ns/op
BenchmarkUint32Div9305  10000000               298 ns/op
BenchmarkUint32Div13307 10000000               298 ns/op
BenchmarkUint32Div52513 10000000               298 ns/op
BenchmarkUint32Div60978747      10000000               298 ns/op
BenchmarkUint32Div106956295     10000000               297 ns/op
BenchmarkUint32Mod7     10000000               280 ns/op
BenchmarkUint32Mod37    10000000               280 ns/op
BenchmarkUint32Mod123   10000000               280 ns/op
BenchmarkUint32Mod763   10000000               280 ns/op
BenchmarkUint32Mod1247  10000000               280 ns/op
BenchmarkUint32Mod9305  10000000               280 ns/op
BenchmarkUint32Mod13307 10000000               280 ns/op
BenchmarkUint32Mod52513 10000000               280 ns/op
BenchmarkUint32Mod60978747      10000000               280 ns/op
BenchmarkUint32Mod106956295     10000000               280 ns/op

R=minux.ma, rsc
CC=golang-dev
https://golang.org/cl/6258067

It's just stutter.

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

Number represents the actual JSON text,
preserving the precision and
formatting of the original input.

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

This is my last one for today, I hope!

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6339052

Fixes #3762.

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

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6325058

go/build section "Build Constraints", first paragraph said:
  "... they must be appear near the top of the file ..."
fixed to:
  "... they must appear near the top of the file ..."

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

Manifest version 1 was deprecated in Chrome 18, and support will be phased
out according to the schedule available at:
http://code.google.com/chrome/extensions/manifestVersion.html

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

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

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6330059

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

Removes an incorrect code comment and some superfluous variables.

The comment I removed says that struct fields which implement
Unmarshaler must be pointers, even if they're in an addressable
struct. That's not the case, and there's already a test in decode_test.go
that demonstrates as much.

Encoding/json has quite a few assignments of reflect.Values to extra
variables – things like "iv := v" when there's no need to make a copy. I
think these are left over from a previous version of the reflect API. If they
aren't wanted, I wouldn't mind going through the package and getting
rid of the rest of them.

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

Fixes #3773.

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

- receiving from a closed channel returns immediately
- in the ,ok form, the 2nd result is of type bool, not
  just boolean (gc and ggcgo agree).

Per dsymonds' suggestion.

R=r, rsc, ken, iant, dsymonds
CC=golang-dev
https://golang.org/cl/6333057

This is a new, not yet committed API.

- Changed NewCommentMap to be independent of
  *File nodes and more symmetric with the
  Filter and Comments methods.

- Implemented Update method for use in
  AST modifications.

- Implemented String method for debugging

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

Fixes #3713.

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

A few performance improvements, but without the stack sorting
change to avoid allocating, which is instead waiting on better
escape analysis.

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

This CL resolves https://golang.org/cl/6300043/#msg3
by renaming memset_arm.s to memclr_arm.s and merging the function
of the same name from asm_arm.s.

R=minux.ma, rsc
CC=golang-dev
https://golang.org/cl/6336054

The issue seems to not be triggered right now,
but I've seen the deadlock after some other legal
modifications to runtime.
So I think we are safer this way.

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

This can only happen if the hash function we're using is getting
far more than it's fair share of collisions, but that has happened
to us repeatedly as we've expanded the allowed use cases for
hash tables (issue 1544, issue 2609, issue 2630, issue 2883, issue 3695).
Maybe this will help the next time we try something new.

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

pkg/math/all_test.go tests Atan (and therefore Asin and Acos) to a
relative accuracy of 4e-16, but the test vector misses values where
the old algorithm was in error by more than that. For example:

x            newError   oldError
0.414215746  1.41e-16  -4.24e-16
0.414216076  1.41e-16  -4.24e-16
0.414217632  1.41e-16  -4.24e-16
0.414218770  1.41e-16  -4.24e-16
0.414225466  0         -5.65e-16
0.414226244  1.41e-16  -4.24e-16
0.414228756  0         -5.65e-16
0.414235089  0         -5.65e-16
0.414237070  0         -5.65e-16

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

Skip directory check in startProcess in the presence of
SysProcAttr.

Fixes #3649.

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

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

Fixes #3732.

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

Fixes #3714.

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

Fixes #3718.

Requires CL 6300043.

R=rsc, minux.ma, extraterrestrial.neighbour
CC=golang-dev
https://golang.org/cl/6305100

Partially fixes issue 3718.

R=golang-dev, rsc, minux.ma
CC=golang-dev
https://golang.org/cl/6300043

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

Note url.Error wrapping, and s/issue/issuing/.

Fixes #3724

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/6294093

        We need to use kernel headers to generate defs_linux_$GOARCH.h

R=golang-dev, dave, alex.brainman, iant
CC=golang-dev
https://golang.org/cl/6296091

Several of my students were confused by trying to use both the error
return and a reply return, so I figured it was worth explicitly clarifying
that returning an error overrides the reply.

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

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

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6337047