faster string operations, and more

tested on linux/386

runtime_test.BenchmarkSliceToString                    642          532  -17.13%
runtime_test.BenchmarkStringToSlice                    636          528  -16.98%
runtime_test.BenchmarkConcatString                    1109          897  -19.12%

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

R=golang-dev, gri, r, agl
CC=golang-dev
https://golang.org/cl/4696046

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

Fixes #1949.

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

Remove static variable from runtime·oldstack().
Benchmark results on HP Z600 (2 x Xeon E5620, 8 HT cores, 2.40GHz)
are as follows (with CL 4657091 applied):
benchmark                                        old ns/op    new ns/op    delta
BenchmarkStackGrowth                               1183.00      1180.00   -0.25%
BenchmarkStackGrowth-2                             1249.00      1211.00   -3.04%
BenchmarkStackGrowth-4                              954.00       805.00  -15.62%
BenchmarkStackGrowth-8                              701.00       683.00   -2.57%
BenchmarkStackGrowth-16                             465.00       415.00  -10.75%

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

TBR=dvyukov
CC=golang-dev
https://golang.org/cl/4710041

Standard-sized stack frames use plain malloc/free
instead of centralized lock-protected FixAlloc.
Benchmark results on HP Z600 (2 x Xeon E5620, 8 HT cores, 2.40GHz)
are as follows:
benchmark                                        old ns/op    new ns/op    delta
BenchmarkStackGrowth                               1045.00       949.00   -9.19%
BenchmarkStackGrowth-2                             3450.00       800.00  -76.81%
BenchmarkStackGrowth-4                             5076.00       513.00  -89.89%
BenchmarkStackGrowth-8                             7805.00       471.00  -93.97%
BenchmarkStackGrowth-16                           11751.00       321.00  -97.27%

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

The new implementation features wait-free
fast path for readers which significantly improves
performance/scalability on read-mostly workloads.
Benchmark results on HP Z600 (2 x Xeon E5620, 8 HT cores, 2.40GHz)
are as follows:
benchmark                              old ns/op    new ns/op    delta
BenchmarkRWMutexUncontended               179.00        96.60  -46.03%
BenchmarkRWMutexUncontended-2              89.10        49.10  -44.89%
BenchmarkRWMutexUncontended-4              44.70        24.70  -44.74%
BenchmarkRWMutexUncontended-8              23.30        12.90  -44.64%
BenchmarkRWMutexUncontended-16             16.80         8.75  -47.92%
BenchmarkRWMutexWrite100                   79.60        26.80  -66.33%
BenchmarkRWMutexWrite100-2                305.00        33.00  -89.18%
BenchmarkRWMutexWrite100-4                245.00       113.00  -53.88%
BenchmarkRWMutexWrite100-8                330.00       147.00  -55.45%
BenchmarkRWMutexWrite100-16               371.00       152.00  -59.03%
BenchmarkRWMutexWrite10                    78.30        29.80  -61.94%
BenchmarkRWMutexWrite10-2                 348.00       165.00  -52.59%
BenchmarkRWMutexWrite10-4                 447.00       199.00  -55.48%
BenchmarkRWMutexWrite10-8                 564.00       180.00  -68.09%
BenchmarkRWMutexWrite10-16                492.00       192.00  -60.98%
BenchmarkRWMutexWorkWrite100             1077.00      1037.00   -3.71%
BenchmarkRWMutexWorkWrite100-2            659.00       596.00   -9.56%
BenchmarkRWMutexWorkWrite100-4            509.00       361.00  -29.08%
BenchmarkRWMutexWorkWrite100-8            603.00       351.00  -41.79%
BenchmarkRWMutexWorkWrite100-16           750.00       607.00  -19.07%
BenchmarkRWMutexWorkWrite10               990.00       951.00   -3.94%
BenchmarkRWMutexWorkWrite10-2            1119.00      1070.00   -4.38%
BenchmarkRWMutexWorkWrite10-4            1300.00      1199.00   -7.77%
BenchmarkRWMutexWorkWrite10-8            1424.00      1291.00   -9.34%
BenchmarkRWMutexWorkWrite10-16           1981.00      1786.00   -9.84%

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

and make and new.

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

Using the CRC32 instruction speeds up the Castagnoli computation by
about 20x on a modern Intel CPU.

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

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

DrawMask already returns early if r.Empty().

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

There are no behavioral changes, only some copy-and-pastes.

Before, drawFillOver was next to drawCopyOver.

After, drawFillOver is next to drawFillSrc, which is more similar to
drawFillOver than drawCopyOver is.

Similarly, drawCopyOver is now next to drawCopySrc, etc.

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

Some benchmark numbers below. The image/draw fast-paths show dramatic
improvement, the generic slow-paths show a smaller slow-down.

BEFORE
png.BenchmarkEncodePaletted      200       8203800 ns/op      37.45 MB/s
png.BenchmarkEncodeRGBOpaque         100      26940440 ns/op      45.61 MB/s
png.BenchmarkEncodeRGBA       20      73821000 ns/op      16.65 MB/s
jpeg.BenchmarkEncodeRGBOpaque         50      35598640 ns/op      34.52 MB/s
draw.BenchmarkFillOver	     500	   4024226 ns/op
draw.BenchmarkFillSrc	   10000	    152736 ns/op
draw.BenchmarkCopyOver	     500	   3452824 ns/op
draw.BenchmarkCopySrc	   50000	     73218 ns/op
draw.BenchmarkNRGBAOver	     500	   3941234 ns/op
draw.BenchmarkNRGBASrc	    1000	   2484400 ns/op
draw.BenchmarkYCbCr	    1000	   2609005 ns/op
draw.BenchmarkGlyphOver	    2000	   1169575 ns/op
draw.BenchmarkRGBA	     200	   9031390 ns/op
draw.BenchmarkGenericOver	      50	  34636620 ns/op
draw.BenchmarkGenericMaskOver	     100	  16561150 ns/op
draw.BenchmarkGenericSrc	     100	  13873760 ns/op
draw.BenchmarkGenericMaskSrc	     100	  25198860 ns/op

AFTER
png.BenchmarkEncodePaletted      200       8206600 ns/op      37.43 MB/s
png.BenchmarkEncodeRGBOpaque         100      26129530 ns/op      47.03 MB/s
png.BenchmarkEncodeRGBA       20      75776750 ns/op      16.22 MB/s
jpeg.BenchmarkEncodeRGBOpaque         50      37192940 ns/op      33.04 MB/s
draw.BenchmarkFillOver	     500	   3008134 ns/op
draw.BenchmarkFillSrc	   10000	    154214 ns/op
draw.BenchmarkCopyOver	    1000	   2169988 ns/op
draw.BenchmarkCopySrc	   50000	     73095 ns/op
draw.BenchmarkNRGBAOver	    1000	   2491079 ns/op
draw.BenchmarkNRGBASrc	    2000	   1361244 ns/op
draw.BenchmarkYCbCr	    1000	   2554269 ns/op
draw.BenchmarkGlyphOver	    2000	   1042225 ns/op
draw.BenchmarkRGBA	     100	  10233340 ns/op
draw.BenchmarkGenericOver	      50	  38421560 ns/op
draw.BenchmarkGenericMaskOver	     100	  17521190 ns/op
draw.BenchmarkGenericSrc	     100	  16351200 ns/op
draw.BenchmarkGenericMaskSrc	     100	  26538190 ns/op

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

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

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

runtime.goidgen can be quite frequently modified and
shares cache line with the following variables,
it leads to false sharing.
50c6b0 b nfname
50c6b4 b nfunc
50c6b8 b nfunc$17
50c6bc b nhist$17
50c6c0 B runtime.checking
50c6c4 B runtime.gcwaiting
50c6c8 B runtime.goidgen
50c6cc B runtime.gomaxprocs
50c6d0 B runtime.panicking
50c6d4 B strconv.IntSize
50c6d8 B src/pkg/runtime/_xtest_.ss
50c6e0 B src/pkg/runtime/_xtest_.stop
50c6e8 b addrfree
50c6f0 b addrmem
50c6f8 b argv

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

Use machine-local random number generator instead of
racy global ones.

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

The data race can lead to erroneous output of
"[invalid string]" instead of a string.

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

R=golang-dev, vcc.163
CC=golang-dev
https://golang.org/cl/4670049

Fixes #2012

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

Without further type informatnion, 1.0 is a float and an integer
must fit in an int.

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

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

R=golang-dev, mirtchovski, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/4686049

makehtml does not work on windows.

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

Breaks Mercurial 1.8.3.

««« original CL description
codereview: fix for Mercurial 1.9

Fixes #2038.

R=rsc, bobbypowers
CC=golang-dev
https://golang.org/cl/4675045
»»»

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

Fixes #2038.

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

This causes the child, if still writing, to get an error or
SIGPIPE and most likely exit so our subsequent wait can
finish.

A more guaranteed fix would be putting a time limit on the
child's overall execution, but this fixes the problem
I was having.

Fixes #2059

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

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

Wasn't actually eager closing the fds as a result of the
copy/paste bug. (GC was doing it instead)

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

This is allowed by the JSON spec and is shorter/easier to read.

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

This is the form as returned by Postgres, as well
as JavaScript.

I've tried and failed to find authorative docs online
about the proper string serialization, if any.

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

Must keep dot and the receiver separate - variables broke that symmetry.
Also clean up function invocation and rename "data" to "dot" for clarity.

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

Replaces "mkdir -p ..." command, as Windows mkdir command
does not support -p flag. Also, is simpler and faster then
launching new process.

R=golang-dev, mattn.jp, adg, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/4626087

Not strictly necessary (you could achieve the same, clumsily,
via with blocks) but great to have: $x.Field, $y.Method.

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

Also explain that len(v)==0 makes v a 'zero value'
in template execution.

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

We can avoid the check against empty constants (''),
which UnquoteChar doesn't handle well, by leaving on
the trailing quote and seeing that's all we have left at the end.

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

Easier to implement than to justify leaving them out.

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

Worth catching at parse time rather than execution. Plus it's really easy.

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

Mistakenly checked in.
Fixes #2058.

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