It's using debug mode of pprof.writeBlock, so the output actually goes
through text/tabwriter. It is possible that tabwriter expands each tab
into multiple tabs in certain cases.

For example, this output has been observed on the new arm64 port:
10073805 1 @ 0x1088ec 0xd1b8c 0xd0628 0xb68c0 0x867f4
#	0x1088ec	sync.(*Cond).Wait+0xfc				/home/minux/go.git/src/sync/cond.go:63
#	0xd1b8c		runtime/pprof_test.blockCond+0x22c		/home/minux/go.git/src/runtime/pprof/pprof_test.go:454
#	0xd0628		runtime/pprof_test.TestBlockProfile+0x1b8	/home/minux/go.git/src/runtime/pprof/pprof_test.go:359
#	0xb68c0		testing.tRunner+0x140				/home/minux/go.git/src/testing/testing.go:447

10069965 1 @ 0x14008 0xd1390 0xd0628 0xb68c0 0x867f4
#	0x14008	runtime.chansend1+0x48				/home/minux/go.git/src/runtime/chan.go:76
#	0xd1390	runtime/pprof_test.blockChanSend+0x100		/home/minux/go.git/src/runtime/pprof/pprof_test.go:396
#	0xd0628	runtime/pprof_test.TestBlockProfile+0x1b8	/home/minux/go.git/src/runtime/pprof/pprof_test.go:359
#	0xb68c0	testing.tRunner+0x140				/home/minux/go.git/src/testing/testing.go:447

10069706 1 @ 0x108e0c 0xd193c 0xd0628 0xb68c0 0x867f4
#	0x108e0c	sync.(*Mutex).Lock+0x19c			/home/minux/go.git/src/sync/mutex.go:67
#	0xd193c		runtime/pprof_test.blockMutex+0xbc		/home/minux/go.git/src/runtime/pprof/pprof_test.go:441
#	0xd0628		runtime/pprof_test.TestBlockProfile+0x1b8	/home/minux/go.git/src/runtime/pprof/pprof_test.go:359
#	0xb68c0		testing.tRunner+0x140				/home/minux/go.git/src/testing/testing.go:447

Change-Id: I3bef778c5fe01a894cfdc526fdc5fecb873b8ade
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/5554Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

Old 45.3 ns/op, new 19.9 ns/op.

Change-Id: If2a201981dcc259846631ecbc694c401e0a80287
Reviewed-on: https://go-review.googlesource.com/5260Reviewed-by: Russ Cox <rsc@golang.org>

Fixes $9938.

Change-Id: Ie8680a875225748abd660fb26b4c25546e7b92d3
Reviewed-on: https://go-review.googlesource.com/5620Reviewed-by: Alan Donovan <adonovan@google.com>

The routine mallocgc retrieves objects from freelists. Prefetch
the object that will be returned in the next call to mallocgc.
Experiments indicate that this produces a 1% improvement when using
prefetchnta and less when using prefetcht0, prefetcht1, or prefetcht2.

Benchmark numbers indicate a 1% improvement over no
prefetch, much less over prefetcht0, prefetcht1, and prefetcht2.
These numbers were for the garbage benchmark with MAXPROCS=4
no prefetch                          >> 5.96 / 5.77 / 5.89
prefetcht0(uintptr(v.ptr().next))    >> 5.88 / 6.17 / 5.84
prefetcht1(uintptr(v.ptr().next))    >> 5.88 / 5.89 / 5.91
prefetcht2(uintptr(v.ptr().next))    >> 5.87 / 6.47 / 5.92
prefetchnta(uintptr(v.ptr().next))   >> 5.72 / 5.84 / 5.85

Change-Id: I54e07172081cccb097d5b5ce8789d74daa055ed9
Reviewed-on: https://go-review.googlesource.com/5350Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Austin Clements <austin@google.com>

Fixes #9948.

Change-Id: I7b354fccd5e933eeeb2253a66acec050ebff6e41
Reviewed-on: https://go-review.googlesource.com/5611Reviewed-by: Alan Donovan <adonovan@google.com>

Change-Id: Ida847365223ef09b4a3846e240b4bb6919cb0fe9
Reviewed-on: https://go-review.googlesource.com/5610Reviewed-by: Alan Donovan <adonovan@google.com>

The code concerning quoted-printable encoding (RFC 2045) and its
variant for MIME headers (RFC 2047) is currently spread in
mime/multipart and net/mail. It is also not exported.

This commit is the second step to fix that issue. It moves the
RFC 2047 encoding and decoding functions from net/mail to
internal/mime. The exported API is unchanged.

Updates #4943

Change-Id: I5f58aa58e74bbe4ec91b2e9b8c81921338053b00
Reviewed-on: https://go-review.googlesource.com/2101Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

We currently have only one supported darwin/arm device, a locked iOS
machine. It requires cgo binaries.

Change-Id: If36a152e6a743e4a58ea3470e62cccb742630a5d
Reviewed-on: https://go-review.googlesource.com/5443Reviewed-by: Russ Cox <rsc@golang.org>

cpp: src/cmd/ld/lib.h:349 No newline at end of file

Change-Id: Id21851963f7778364ba9337da3bacd312443f51f
Reviewed-on: https://go-review.googlesource.com/5520Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I239ae86cfebfece607dce39a96d9123cbacbee7d
Reviewed-on: https://go-review.googlesource.com/5562
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I05cdf357249166a45105703e9317793aa2088844
Reviewed-on: https://go-review.googlesource.com/5560Reviewed-by: Andrew Gerrand <adg@golang.org>

With a trivial Golang-built program loaded in gdb-7.8.90.20150214-7.fc23.x86_64
I get this error:

(gdb) source ./src/runtime/runtime-gdb.py
Loading Go Runtime support.
Traceback (most recent call last):
  File "./src/runtime/runtime-gdb.py", line 230, in <module>
    _rctp_type = gdb.lookup_type("struct reflect.rtype").pointer()
gdb.error: No struct type named reflect.rtype.
(gdb) q

No matter if this struct should or should not be in every Golang-built binary
this change should fix that with no disadvantages.

Change-Id: I0c490d3c9bbe93c65a2183b41bfbdc0c0f405bd1
Reviewed-on: https://go-review.googlesource.com/5521Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I6011e162214db2d65efc1ecdb5ec600ca8e5bfe9
Reviewed-on: https://go-review.googlesource.com/5542Reviewed-by: Ian Lance Taylor <iant@golang.org>

Trace command allows to visualize and analyze traces.
Run as:
$ go tool trace binary trace.file
The commands opens web browser with the main page,
which contains links for trace visualization,
blocking profiler, network IO profiler and per-goroutine
traces.

Also move trace parser from runtime/pprof/trace_parser_test.go
to internal/trace/parser.go, so that it can be shared between
tests and the command.

Change-Id: Ic97ed59ad6e4c7e1dc9eca5e979701a2b4aed7cf
Reviewed-on: https://go-review.googlesource.com/3601Reviewed-by: Andrew Gerrand <adg@golang.org>

Fixes #9720
Fixes #8053
Fixes https://code.google.com/p/thread-sanitizer/issues/detail?id=89

Change-Id: I7d598e53de86586bb9702d8e9276a4d6aece2dfc
Reviewed-on: https://go-review.googlesource.com/4950Reviewed-by: Ian Lance Taylor <iant@golang.org>

In most cases we pass return PC to race detector,
and race runtime subtracts one from them.
However, in manual instrumentation in runtime
we pass function start PC to race runtime.
Race runtime can't distinguish these cases
and so it does not subtract one from top PC.
This leads to bogus line numbers in some cases.
Make it consistent and always pass what looks
like a return PC, so that race runtime can
subtract one and still get PC in the same function.

Also delete two unused functions.

Update #8053

Change-Id: I4242dec5e055e460c9a8990eaca1d085ae240ed2
Reviewed-on: https://go-review.googlesource.com/4902Reviewed-by: Ian Lance Taylor <iant@golang.org>

This is a nice split but more importantly it provides a better
way to fit the checkmark phase into the sequencing.

Also factor out common span copying into gcSpanCopy.

Change-Id: Ia058644974e4ed4ac3cf4b017a3446eb2284d053
Reviewed-on: https://go-review.googlesource.com/5333Reviewed-by: Austin Clements <austin@google.com>

The loop made more sense when gc_m was not its own function.

Change-Id: I71a7f21d777e69c1924e3b534c507476daa4dfdd
Reviewed-on: https://go-review.googlesource.com/5332Reviewed-by: Austin Clements <austin@google.com>

Change-Id: I0da26e89ae73272e49e82c6549c774e5bc97f64c
Reviewed-on: https://go-review.googlesource.com/5331Reviewed-by: Austin Clements <austin@google.com>

See the following issue for context:
https://github.com/golang/go/issues/9729#issuecomment-74648287
In short, RDTSC can produce skewed results without preceding LFENCE/MFENCE.
Information on this matter is very scrappy in the internet.
But this is what linux kernel does (see rdtsc_barrier).
It also fixes the test program on my machine.

Update #9729

Change-Id: I3c1ffbf129fdfdd388bd5b7911b392b319248e68
Reviewed-on: https://go-review.googlesource.com/5033Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #9928

Change-Id: Iab37051078755a132f211ad48e756422f7c55a39
Reviewed-on: https://go-review.googlesource.com/5416Reviewed-by: Minux Ma <minux@golang.org>

This changes fixes two issues with regard to handling routing messages
as follows:
- Misparsing on platforms (such as FreeBSD) supporting multiple
  architectures in the same kernel (kern.supported_archs="amd64 i386")
- Misparsing with unimplemented messages such as route, interface
  address state notifications

To fix those issues, this change implements all the required socket
address parsers, adds a processor architecture identifying function to
FreeBSD and tests.

Fixes #9707.
Fixes #8203.

Change-Id: I7ed7b4a0b6f10f54b29edc681a2f35603f2d8d45
Reviewed-on: https://go-review.googlesource.com/4330Reviewed-by: Ian Lance Taylor <iant@golang.org>

Before Go 1.4, the traditional way to work with a private Github
repository was to run something similar the following:

```
git config --global url."git@github.com:".insteadOf "https://github.com/"
```

It would allow go get and friends to transparently work as expected,
automatically rewriting https URLs to use SSH for auth. This worked both
when pushing and pulling.

In Go 1.4 this broke, now requiring the use of `go get -f` instead of `go get`
in order to fetch private repositories. This seems neither intended nor
practical, as it requires changing a lot of tooling.

So just use `git config remote.origin.url` instead of `git remote -v` as
this reflects the actual substitution intended in the `insteadOf` config
directive.

Also remove now useless parsing.

Also add a check against supported schemes to avoid errors in later
commands using this URL and expecting such a scheme.

Fixes #9697

Change-Id: I907327f83504302288f913a68f8222a5c2d673ee
Reviewed-on: https://go-review.googlesource.com/3504Reviewed-by: Andrew Gerrand <adg@golang.org>

Change-Id: I678336daf99f7d7d19f99506f1a604de8e05bf43
Reviewed-on: https://go-review.googlesource.com/5400Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #9932

Change-Id: I7943470a1784278a5c6e99c3b66c59d4953734ba
Reviewed-on: https://go-review.googlesource.com/5340Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This is causing crashes.

Change-Id: I1832f33d114bc29894e491dd2baac45d7ab3a50d
Reviewed-on: https://go-review.googlesource.com/5330Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

That is, I accidentally dropped this change of Austin's
when preparing my CL. I blame Git.

Change-Id: I9dd772c84edefad96c4b16785fdd2dea04a4a0d6
Reviewed-on: https://go-review.googlesource.com/5320Reviewed-by: Austin Clements <austin@google.com>

Move code from malloc1.go, malloc2.go, mem.go, mgc0.go into
appropriate locations.

Factor mgc.go into mgc.go, mgcmark.go, mgcsweep.go, mstats.go.

A lot of this code was in certain files because the right place was in
a C file but it was written in Go, or vice versa. This is one step toward
making things actually well-organized again.

Change-Id: I6741deb88a7cfb1c17ffe0bcca3989e10207968f
Reviewed-on: https://go-review.googlesource.com/5300Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>

The flag disables stripping of runtime frames in profiles.
This is useful when analyzing runtime itself.

Before:
$ go tool pprof --text --alloc_objects --lines fmt.test /tmp/mprof
      flat  flat%   sum%        cum   cum%
      2768 79.65% 79.65%      32768 79.65%  fmt_test.TestComplexFormatting fmt/fmt_test.go:744
      6554 15.93% 95.58%       6554 15.93%  regexp/syntax.(*compiler).rune regexp/syntax/compile.go:267
      1820  4.42%   100%       1820  4.42%  runtime.malg runtime/proc1.go:1977

After:
$ go tool pprof --text --alloc_objects --lines --runtime fmt.test /tmp/mprof
      flat  flat%   sum%        cum   cum%
     32768 79.65% 79.65%      32768 79.65%  runtime.convT2E runtime/iface.go:139
      6554 15.93% 95.58%       6554 15.93%  runtime.growslice runtime/slice.go:89
      1820  4.42%   100%       1820  4.42%  runtime.malg runtime/proc1.go:1977

Change-Id: If468dfa5c5bbd0809c45a58d912d3115fac009ed
Reviewed-on: https://go-review.googlesource.com/5291Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Fixes #9927

Change-Id: I2114cc21f7a4772e3d42bcad9642a8a545cd8e16
Reviewed-on: https://go-review.googlesource.com/5285Reviewed-by: Minux Ma <minux@golang.org>

Until recently, struct workbuf had only lfnode and uintptr fields
before the obj array to make it convenient to compute the size of the
obj array.  It slowly grew more fields until this became inconvenient
enough that it was restructured to make the size computation easy.
Now the size computation doesn't care what the field types are, so
switch to more natural types.

Change-Id: I966140ba7ebb4aeb41d5c66d9d2a3bdc17dd4bcf
Reviewed-on: https://go-review.googlesource.com/5262Reviewed-by: Russ Cox <rsc@golang.org>

This converts the garbage collector from directly manipulating work
buffers to using the new gcWork abstraction.

The previous management of work buffers was rather ad hoc.  As a
result, switching to the gcWork abstraction changes many details of
work buffer management.

If greyobject fills a work buffer, it can now pull from work.partial
in addition to work.empty.

Previously, gcDrain started with a partial or empty work buffer and
fetched an empty work buffer if it filled its current buffer (in
greyobject).  Now, gcDrain starts with a full work buffer and fetches
an partial or empty work buffer if it fills its current buffer (in
greyobject).  The original behavior was bad because gcDrain would
immediately drop the empty work buffer returned by greyobject and
fetch a full work buffer, which greyobject was likely to immediately
overflow, fetching another empty work buffer, etc.  The new behavior
isn't great at the start because greyobject is likely to immediately
overflow the full buffer, but the steady-state behavior should be more
stable.  Both before and after this change, gcDrain fetches a full
work buffer if it drains its current buffer.  Basically all of these
choices are bad; the right answer is to use a dual work buffer scheme.

Previously, shade always fetched a work buffer (though usually from
m.currentwbuf), even if the object was already marked.  Now it only
fetches a work buffer if it actually greys an object.

Change-Id: I8b880ed660eb63135236fa5d5678f0c1c041881f
Reviewed-on: https://go-review.googlesource.com/5232Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

This introduces a producer/consumer abstraction for GC work pointers
that internally handles the details of filling, draining, and
shuffling work buffers.

In addition to simplifying the GC code, this should make it easy for
us to change how we use work buffers, including cleaning up how we use
the work.partial queue, reintroducing a FIFO lookahead cache, adding
prefetching, and using dual buffers to avoid flapping.

This commit doesn't change any existing code.  The following commit
will switch the garbage collector from explicit workbuf manipulation
to gcWork.

Change-Id: Ifbfe5fff45bf0362d6d7c3cecb061f0c9874077d
Reviewed-on: https://go-review.googlesource.com/5231Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Change-Id: If7729b3c7df6dc7fcd41f293e2ef2472c769fe8b
Reviewed-on: https://go-review.googlesource.com/5261Reviewed-by: Rick Hudson <rlh@golang.org>

Change-Id: I73450aeb59571f3285ff59ae214739e1866c9aa0
Reviewed-on: https://go-review.googlesource.com/5270Reviewed-by: Andrew Gerrand <adg@golang.org>

frames.

Fixes #9888.

Change-Id: I60f1d843e72e1b7bc77ab984f149c9ddb5258a06
Reviewed-on: https://go-review.googlesource.com/5251Reviewed-by: Rob Pike <r@golang.org>

Nit.  There's no reason to take a uintptr and doing so just requires
casts in annoying places.

Change-Id: Ifeb9638c6d94eae619c490930cf724cc315680ba
Reviewed-on: https://go-review.googlesource.com/5230Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I2de63668a1c0152cc329df55c2d6d014e8183158
Reviewed-on: https://go-review.googlesource.com/4943Reviewed-by: Minux Ma <minux@golang.org>

The comment previously was reversed in sense (it appeared to be
describing unmarshaling). I've fixed that, and added the caveat that map
keys are subject to UTF-8 coercion like other strings.

Change-Id: Id08082aa71401a6e7530a42f979fbb50bd1f4e6a
Reviewed-on: https://go-review.googlesource.com/5221
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

if their nominal Min and Max points differ.

This is a behavior change, but arguably a bug fix, as Eq wasn't
previously consistent with In, and the concept of a rectangle being a
set of points. This is demonstrated by the new geom_test.go test.

It does mean that r.Eq(s) no longer implies that Inset'ting both r and s
with a negative inset results in two rectangles that are still Eq, but
that seems acceptable to me.

The previous behavior is still available as "r == s".

Also clarify the image.Rect doc comment when the inputs are
non-canonical.

Also simplify the Point and Rectangle Eq implementations dating from
before Go 1.0, when you couldn't compare structs via the == operator.

Change-Id: Ic39e628db31dc5fe5220f4b444e6d5000eeace5b
Reviewed-on: https://go-review.googlesource.com/5006Reviewed-by: Rob Pike <r@golang.org>