R=golang-dev, gri
CC=golang-dev, miki.tebeka
https://golang.org/cl/5225042

Linux/amd64, 2 x Intel Xeon E5620, 8 HT cores, 2.40GHz
benchmark                    old ns/op    new ns/op    delta
BenchmarkFinalizer              420.00       261.00  -37.86%
BenchmarkFinalizer-2            985.00       201.00  -79.59%
BenchmarkFinalizer-4           1077.00       244.00  -77.34%
BenchmarkFinalizer-8           1155.00       180.00  -84.42%
BenchmarkFinalizer-16          1182.00       184.00  -84.43%

BenchmarkFinalizerRun          2128.00      1378.00  -35.24%
BenchmarkFinalizerRun-2        1655.00      1418.00  -14.32%
BenchmarkFinalizerRun-4        1634.00      1522.00   -6.85%
BenchmarkFinalizerRun-8        2213.00      1581.00  -28.56%
BenchmarkFinalizerRun-16       2424.00      1599.00  -34.03%

Darwin/amd64, Intel L9600, 2 cores, 2.13GHz
benchmark                    old ns/op    new ns/op    delta
BenchmarkChanCreation          1451.00       926.00  -36.18%
BenchmarkChanCreation-2        3124.00      1412.00  -54.80%
BenchmarkChanCreation-4        6121.00      2628.00  -57.07%

BenchmarkFinalizer              684.00       420.00  -38.60%
BenchmarkFinalizer-2          11195.00       398.00  -96.44%
BenchmarkFinalizer-4          15862.00       654.00  -95.88%

BenchmarkFinalizerRun          2025.00      1397.00  -31.01%
BenchmarkFinalizerRun-2        3920.00      1447.00  -63.09%
BenchmarkFinalizerRun-4        9471.00      1545.00  -83.69%

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

The malloc sample trigger was not being set in a
new m, so the first allocation in each new m - the
goroutine structure - was being sampled with
probability 1 instead of probability sizeof(G)/rate,
an oversampling of about 5000x for the default
rate of 1 MB.  This bug made pprof graphs show
far more G allocations than there actually were.

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

Fixes #2337.
Unfortunate sequence of events is:
1. maxcpu=2, mcpu=1, grunning=1
2. starttheworld creates an extra M:
   maxcpu=2, mcpu=2, grunning=1
4. the goroutine calls runtime.GOMAXPROCS(1)
   maxcpu=1, mcpu=2, grunning=1
5. since it sees mcpu>maxcpu, it calls gosched()
6. schedule() deschedules the goroutine:
   maxcpu=1, mcpu=1, grunning=0
7. schedule() call getnextandunlock() which
   fails to pick up the goroutine again,
   because canaddcpu() fails, because mcpu==maxcpu
8. then it sees that grunning==0,
   reports deadlock and terminates

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

R=golang-dev, alex.brainman
CC=golang-dev
https://golang.org/cl/5201042

R=rsc, jp, hectorchu
CC=golang-dev
https://golang.org/cl/4962051

therefore unlikely that there is a good use for its string version
LastBoundaryInString. Yet, the implemenation of this method would complicate
things a bit as it would require the introduction for another interface and
some duplication of code. Removing it seems a better choice.

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

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

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

binary.BenchmarkPutUvarint32 20000000	 85.6 ns/op
binary.BenchmarkPutUvarint64 10000000	299   ns/op

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

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

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

Major changes between hybi-08 and hybi-13
- hybi-08 uses Sec-WebSocket-Origin, but hybi-13 uses Origin
- hybi-13 introduces new close status codes.

hybi-17 spec (editorial changes of hybi-13) mentions
- if a server doesn't support the requested version, it MUST respond
  with Sec-WebSocket-Version headers containing all available versions.
- client MUST close the connection upon receiving a masked frame
- server MUST close the connection upon receiving a non-masked frame
note that hybi-17 still uses "Sec-WebSocket-Version: 13"

see http://code.google.com/p/pywebsocket/wiki/WebSocketProtocolSpec
for changes between spec drafts.

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

R=adg, cw, lvd
CC=golang-dev
https://golang.org/cl/5168046

of methods.

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

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

Set the runtime ncpu based on the hw.ncpu sysctl.

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

This can work only if there is no type info required to initialize the decoder,
but it's easy and gains a few percent in the basic benchmarks by avoiding
bufio when it's a bytes.Buffer - a testing-only scenario, I admit.
Add a comment about what Decode expects from the input.

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

Must use case-sensitive search to identify keywords.

Fixes #2287.

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

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

When ncpu < 2, work.nproc is always 1 which results in infinite helper
threads being created if gomaxprocs > 1 and MaxGcproc > 1. Avoid this
by using the same limits as imposed helpgc().

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

This change adds the osyield and usleep
functions and code to read the number of
processors from /dev/sysstat.

I also changed SysAlloc to return nil
when brk fails (it was returning -1).

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

lib/codereview: Unable to use vim for 'hg change' from windows console
reload(sys) break workaround for windows.
see:
http://mercurial.selenic.com/bts/issue2888
http://mercurial.selenic.com/bts/issue1452
Also does not work with backslash paths.

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

This requires making the .dynamic section writable, as the
dynamic linker will change the value of the DT_DEBUG tag at
runtime.  The DT_DEBUG tag is used by gdb to find all loaded
shared libraries.

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

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

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

Fixes #2324.

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

The loop recognizer uses the standard dominance
frontiers but gets confused by dead code, which
has a (not explicitly set) rpo number of 0, meaning it
looks like the head of the function, so it dominates
everything.  If the loop recognizer encounters dead
code while tracking backward through the graph
it fails to recognize where it started as a loop, and
then the optimizer does not registerize values loaded
inside that loop.  Fix by checking rpo against rpo2r.

Separately, run a quick pass over the generated
code to squash JMPs to JMP instructions, which
are convenient to emit during code generation but
difficult to read when debugging the -S output.
A side effect of this pass is to eliminate dead code,
so the output files may be slightly smaller and the
optimizer may have less work to do.
There is no semantic effect, because the linkers
flatten JMP chains and delete dead instructions
when laying out the final code.  Doing it here too
just makes the -S output easier to read and more
like what the final binary will contain.

The "dead code breaks loop finding" bug is thus
fixed twice over.  It seemed prudent to fix loopit
separately just in case dead code ever sneaks back
in for one reason or another.

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

R=golang-dev, rsc, gustavo, r, borman
CC=golang-dev
https://golang.org/cl/4981049

Example: #cgo windows LDFLAGS: -LC:\\WINDOWS\\system32

R=alex.brainman, go.peter.90, golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5154042

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

The spin-off renames some types. The new names are simply better:
image.Color              -> color.Color
image.ColorModel         -> color.Model
image.ColorModelFunc     -> color.ModelFunc
image.PalettedColorModel -> color.Palette
image.RGBAColor          -> color.RGBA
image.RGBAColorModel     -> color.RGBAModel
image.RGBA64Color        -> color.RGBA64
image.RGBA64ColorModel   -> color.RGBA64Model
(similarly for NRGBAColor, GrayColorModel, etc)

The image.ColorImage type stays in the image package, but is renamed:
image.ColorImage -> image.Uniform

The image.Image implementations (image.RGBA, image.RGBA64, image.NRGBA,
image.Alpha, etc) do not change their name, and gain a nice symmetry:
an image.RGBA is an image of color.RGBA, etc.

The image.Black, image.Opaque uniform images remain unchanged (although
their type is renamed from image.ColorImage to image.Uniform). The
corresponding color types (color.Black, color.Opaque, etc) are new.

Nothing in the image/ycbcr is renamed yet. The ycbcr.YCbCrColor and
ycbcr.YCbCrImage types will eventually migrate to color.YCbCr and
image.YCbCr, but that will be a separate CL.

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

Fix for new regexp library ($ isn't end of line any more).
Don't assume . is in PATH.

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

This implements a replacer for when all old strings are single
bytes, but new values are not.

BenchmarkHTMLEscapeNew   1000000   1090 ns/op
BenchmarkHTMLEscapeOld   1000000   2049 ns/op

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

My previous CL:

changeset:   9645:ce2e5f44b310
user:        Russ Cox <rsc@golang.org>
date:        Tue Sep 06 10:24:21 2011 -0400
summary:     gc: unify stack frame layout

introduced a bug wherein no variables were
being registerized, making Go programs 2-3x
slower than they had been before.

This CL fixes that bug (along with some others
it was hiding) and adds a test that optimization
makes at least one test case faster.

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

When all old & new string values are single bytes,
byteReplacer is now used, instead of the generic
algorithm.

BenchmarkGenericMatch       10000  102519 ns/op
BenchmarkByteByteMatch    1000000    2178 ns/op

fast path, when nothing matches:
BenchmarkByteByteNoMatch  1000000    1109 ns/op

comparisons to multiple Replace calls:
BenchmarkByteByteReplaces  100000   16164 ns/op

comparison to strings.Map:
BenchmarkByteByteMap       500000    5454 ns/op

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

R=golang-dev, jsing, alex.brainman, cw, rsc
CC=golang-dev
https://golang.org/cl/5166047

R=golang-dev, mikioh.mikioh, hectorchu
CC=golang-dev
https://golang.org/cl/5173043

The map implementation was using the C idiom of using
a pointer just past the end of its table as a limit pointer.
Unfortunately, the garbage collector sees that pointer as
pointing at the block adjacent to the map table, pinning
in memory a block that would otherwise be freed.

Fix by making limit pointer point at last valid entry, not
just past it.

Reviewed by Mike Burrows.

R=golang-dev, bradfitz, lvd, r
CC=golang-dev
https://golang.org/cl/5158045

R=golang-dev, dave
CC=golang-dev
https://golang.org/cl/5137042