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>

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

Env vars were incorrectly copying whole value of http.RemoteAddr
to REMOTE_ADDR and REMOTE_HOST. They contained IP:port pair which
instead should only have IP (RFC 3875, other sources).

Module also was not setting REMOTE_PORT variable which become de-facto
standard for passing TCP client port to CGI scripts (Apache mod_cgi,
IIS, and probably others)

Fixes #9861

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

Change-Id: Ia6b06f19e5ac424f01a1b90b78b507363b0c4577
Reviewed-on: https://go-review.googlesource.com/5061Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

In CL 3964, NULL was used instead of nil.
However, Plan 9 doesn't declare NULL.

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

Fixes #8291

There were several complaints about closure names in the issue tracker.
The first problem is that you see names like net/http.func·001
in profiles, traces, etc. And there is no way to figure out what
is that function.
Another issue is non-US-ascii symbols. All programs out there
should accept UTF-8. But unfortunately it is not true in reality.
For example, less does not render middle dot properly.

This change prepends outer function name to closure name and
replaces middle dot with dot. Now names look like:

main.glob.func1
main.glob.func2
main.glob.func2.1
main.init.1
main.init.1.func1
main.init.1.func1.1
main.main.func1
main.main.func1.1

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

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

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

Apparently when ARM stops at a GDB breakpoint, it appears to be in
syscall.Syscall.  The "info goroutines" test expected it to be in a
runtime function.  Since this isn't fundamental to the test, simply
tweak the test's regexp to make sure "info goroutines" prints some
running goroutine with an active M, but don't require it to be in any
particular function.

Change-Id: Iba2618b46d3dc49cef62ffb72484b83ea7b0317d
Reviewed-on: https://go-review.googlesource.com/5060Reviewed-by: Dave Cheney <dave@cheney.net>

All of the other memory-related source files start with "m".  Keep up
the tradition.

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