And vice versa.

The flags are tightly coupled so make the connection clear.

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

This CL removes the single and racy use of mheap.arena_end outside
of the bookkeeping done in mHeap_init and mHeap_Alloc.
There should be no way for heapBitsForSpan to see a pointer to
an invalid span. This CL makes the check for this more precise by
checking that the pointer is between mheap_.arena_start and
mheap_.arena_used instead of mheap_.arena_end.

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

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

In order to avoid a race with a concurrent write barrier or garbage
collector thread, any update to arena_used must be preceded by mapping
the corresponding heap bitmap and spans array memory. Otherwise, the
concurrent access may observe that a pointer falls within the heap
arena, but then attempt to access unmapped memory to look up its span
or heap bits.

Commit d57c889a fixed all of the places where we updated arena_used
immediately before mapping the heap bitmap and spans, but it missed
the one place where we update arena_used and depend on later code to
update it again and map the bitmap and spans. This creates a window
where the original race can still happen. This commit fixes this by
mapping the heap bitmap and spans before this arena_used update as
well. This code path is only taken when expanding the heap reservation
on 32-bit over a hole in the address space, so these extra mmap calls
should have negligible impact.

Fixes #10212, #11324.

Change-Id: Id67795e6c7563eb551873bc401e5cc997aaa2bd8
Reviewed-on: https://go-review.googlesource.com/11340
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

The unsynchronized accesses to mheap_.arena_used in the concurrent
part of the garbage collector look like a problem waiting to happen.
In fact, they are safe, but the reason is somewhat subtle and
undocumented. This commit documents this reasoning.

Related to issue #9984.

Change-Id: Icdbf2329c1aa11dbe2396a71eb5fc2a85bd4afd5
Reviewed-on: https://go-review.googlesource.com/11254Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

Historically we have declined to try to provide real support for URLs
that contain %2F in the path, but they seem to be popping up more
often, especially in (arguably ill-considered) REST APIs that shoehorn
entire paths into individual path elements.

The obvious thing to do is to introduce a URL.RawPath field that
records the original encoding of Path and then consult it during
URL.String and URL.RequestURI. The problem with the obvious thing
is that it breaks backward compatibility: if someone parses a URL
into u, modifies u.Path, and calls u.String, they expect the result
to use the modified u.Path and not the original raw encoding.

Split the difference by treating u.RawPath as a hint: the observation
is that there are many valid encodings of u.Path. If u.RawPath is one
of them, use it. Otherwise compute the encoding of u.Path as before.

If a client does not use RawPath, the only change will be that String
selects a different valid encoding sometimes (the original passed
to Parse).

This ensures that, for example, HTTP requests use the exact
encoding passed to http.Get (or http.NewRequest, etc).

Also add new URL.EscapedPath method for access to the actual
escaped path. Clients should use EscapedPath instead of
reading RawPath directly.

All the old workarounds remain valid.

Fixes #5777.
Might help #9859.
Fixes #7356.
Fixes #8767.
Fixes #8292.
Fixes #8450.
Fixes #4860.
Fixes #10887.
Fixes #3659.
Fixes #8248.
Fixes #6658.
Reduces need for #2782.

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

The test was translated from shell incorrectly,
and it depended on having hg installed, which
may not be the case.

Moved repo to GitHub, updated code, and fixed
go list ... command to be expected to succeed.

Fixes test for #8181.

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

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

In the parser, the shift value is always a uint64.

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

A header of ": value" results in an empty key. Do not add
it to the headers, because RFC7230 (section 3.2) says that
field-names are tokens, which are one or more characters.

Fixes #11205.

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

Fixes #11278.

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

Most important: skip test on darwin/arm64 for unclear reasons.

First cut at the test missed this feature of go doc: when asking for
the docs for a type, include any function that looks like it constructs
a that type as a return value.

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

Some Linux kernels apparently have a sysctl that prohibits
nonprivileged processes from creating user namespaces.  If we see a
failure for that reason, skip the test.

Fixes #11261.

Change-Id: I82dfcaf475eea4eaa387941373ce7165df4848ad
Reviewed-on: https://go-review.googlesource.com/11269Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>

nacl is really giving a hard time. avoid all external dependencies in the test.
Worked with trybots, failed in the build. No explanation, but this should fix it.

TBR=rsc

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

Refactor main a bit to make it possible to run tests without an exec every time.
(Makes a huge difference in run time.)

Add a silver test. Not quite golden, since it looks for pieces rather than the
full output, and also includes tests for what should not appear.

Fixes #10920.

Change-Id: I6a4951cc14e61763379754a10b0cc3484d30c267
Reviewed-on: https://go-review.googlesource.com/11272Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Rob Pike <r@golang.org>

This sometime worries new contributors.
Hopefully mentioning it here will help.

Fixes #11300.

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

All of the heavy-lifting was done by minux@, with his external-linking support
for darwin/arm64: golang.org/cl/8781

Change-Id: I7c9fbc19246f418c065c92fb2c13c00026ff0f82
Reviewed-on: https://go-review.googlesource.com/11127
Run-TryBot: Srdjan Petrovic <spetrovic@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

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

Fixes #11284.

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

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

When GO15VENDOREXPERIMENT=1 is in the environment,
this CL changes the resolution of import paths according to
the Go 1.5 vendor proposal:

	If there is a source directory d/vendor, then,
	when compiling a source file within the subtree rooted at d,
	import "p" is interpreted as import "d/vendor/p" if that exists.

	When there are multiple possible resolutions,
	the most specific (longest) path wins.

	The short form must always be used: no import path can
	contain “/vendor/” explicitly.

	Import comments are ignored in vendored packages.

The goal of these changes is to allow authors to vendor (copy) external
packages into their source trees without any modifications to the code.
This functionality has been achieved in tools like godep, nut, and gb by
requiring GOPATH manipulation. This alternate directory-based approach
eliminates the need for GOPATH manipulation and in keeping with the
go command's use of directory layout-based configuration.

The flag allows experimentation with these vendoring semantics once
Go 1.5 is released, without forcing them on by default. If the experiment
is deemed a success, the flag will default to true in Go 1.6 and then be
removed in Go 1.7.

For more details, see the original proposal by Keith Rarick at
https://groups.google.com/d/msg/golang-dev/74zjMON9glU/dGhnoi2IMzsJ.

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

The -importmap option takes an argument of the form old=new
and specifies that import "old" should be interpreted as if it said
import "new". The option may be repeated to specify multiple mappings.

This option is here to support the go command's new -vendor flag.

Change-Id: I31b4ed4249b549982a720bf61bb230462b33c59b
Reviewed-on: https://go-review.googlesource.com/10922Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Currently its possible for the garbage collector to observe
uninitialized memory or stale heap bitmap bits on weakly ordered
architectures such as ARM and PPC. On such architectures, the stores
that zero newly allocated memory and initialize its heap bitmap may
move after a store in user code that makes the allocated object
observable by the garbage collector.

To fix this, add a "publication barrier" (also known as an "export
barrier") before returning from mallocgc. This is a store/store
barrier that ensures any write done by user code that makes the
returned object observable to the garbage collector will be ordered
after the initialization performed by mallocgc. No barrier is
necessary on the reading side because of the data dependency between
loading the pointer and loading the contents of the object.

Fixes one of the issues raised in #9984.

Change-Id: Ia3d96ad9c5fc7f4d342f5e05ec0ceae700cd17c8
Reviewed-on: https://go-review.googlesource.com/11083Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Martin Capitanio <capnm9@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>

These tests were broken by https://go-review.googlesource.com/#/c/11227/
which fixed the LZW encoder to reject invalid input.

For TestNoPalette, the LZW encoder with a litWidth of 2 now rejects an
input byte of 128, so we change 128 to 3, as 3 <= (1<<2 - 1).

For TestPixelOutsidePaletteRange, the LZW encoder similarly rejects an
input byte of 255. Prior to golang.org/cl/11227, the encoder (again with
a litWidth of 2) accepted the 255 input byte, but masked it with (1<<2 -
1), so that the 255 test case was effectively the same as the 3 test
case. After that LZW CL, the 255 input byte is simply invalid, so we
remove it as a test case. The test still tests pixels outside of the
palette range, since 3 >= the length of the global palette, which is 2.

Change-Id: I50be9623ace016740e34801549c15f83671103eb
Reviewed-on: https://go-review.googlesource.com/11273Reviewed-by: David Symonds <dsymonds@golang.org>

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

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

This is a documentation fix that reflects the current reality.

Fixes #9673.

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

Fixes #4210.

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

This also includes some other minor updates to the documentation.

Change-Id: Iafab353727d7622d125b97fbdeaa81525b7a92aa
Reviewed-on: https://go-review.googlesource.com/11123Reviewed-by: Yves Junqueira <yves.junqueira@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>

Indent the temporary file source code embedded in go_test.go, so that
we don't have temporary Go code in the first column.

No real changes to the tests, just formatting.

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

Spell out what will happen if a declaration and definition is included
in the same file, should help people who run into duplicate symbol
errors and search for relevant keywords.

This edit is based on opening issue #11263 erroneously.

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

Change-Id: I97812575ff9c69301a5ce2e1c814b40e1da32a55
Reviewed-on: https://go-review.googlesource.com/11271Reviewed-by: David Crawshaw <crawshaw@golang.org>

Updates #11268.

Change-Id: Ib0cabd1c1806e884df9e40f6a9a1cdecf2f76823
Reviewed-on: https://go-review.googlesource.com/11223Reviewed-by: David Crawshaw <crawshaw@golang.org>

A frame that tries to use the global palette when it has
not been given should result in an error, not an image
with no palette at all.

Fixes #11150.

Change-Id: If0c3a201a0ac977eee2b7a5dc68930c0c5787f40
Reviewed-on: https://go-review.googlesource.com/11064Reviewed-by: Nigel Tao <nigeltao@golang.org>

The compress/lzw encoder now rejects too-large input bytes, as of
https://go-review.googlesource.com/#/c/11227/, so we can't generate bad
GIFs programatically.

Change-Id: I0b32ce8e1f1776cd6997869db61e687430464e45
Reviewed-on: https://go-review.googlesource.com/11270Reviewed-by: Nigel Tao <nigeltao@golang.org>

Fixes #11142.

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

Change-Id: Id9e8c3f89e021b9f389ab3c8403e6a8450fa9f5f
Reviewed-on: https://go-review.googlesource.com/11231Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Add sentences to the docs explaining the limit on input
bytes implicit in the choice of litWidth, and the fact that
compress and decompress litWidth must match.

Fixes #11142.

Change-Id: I20cfb4df35739f7bfeb50b92c78249df3d47942c
Reviewed-on: https://go-review.googlesource.com/11063Reviewed-by: Nigel Tao <nigeltao@golang.org>

Some latency regressions have crept into our system over the past few
weeks. This CL fixes those by having the mark phase more aggressively
blacken objects so that the mark termination phase, a STW phase, has less
work to do. Three approaches were taken when the mark phase believes
it has no more work to do, ie all the work buffers are empty.
If things have gone well the mark phase is correct and there is
in fact little or no work. In that case the following items will
take very little time. If the mark phase is wrong this CL will
ferret that work out and give the mark phase a chance to deal with
it concurrently before mark termination begins.

When the mark phase first appears to be out of work, it does three things:
1) It switches from allocating white to allocating black to reduce the
number of unmarked objects reachable only from stacks.
2) It flushes and disables per-P GC work caches so all work must be in
globally visible work buffers.
3) It rescans the global roots---the BSS and data segments---so there
are fewer objects to blacken during mark termination. We do not rescan
stacks at this point, though that could be done in a later CL.
After these steps, it again drains the global work buffers.

On a lightly loaded machine the garbage benchmark has reduced the
number of GC cycles with latency > 10 ms from 83 out of 4083 cycles
down to 2 out of 3995 cycles. Maximum latency was reduced from
60+ msecs down to 20 ms.

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

Change-Id: I157879f5204d543eb3fc81c212d563b146473ba8
Reviewed-on: https://go-review.googlesource.com/11232Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>