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>

Updates #11241

Change-Id: I573be85d0cfcf410f6125ecd2be8a3d292c40bbb
Reviewed-on: https://go-review.googlesource.com/11245Reviewed-by: Robert Griesemer <gri@golang.org>

See also issue #11271.

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

When a method is called using the Type.Method(receiver, args...) syntax
without the receiver, or enough arguments, provide the more helpful
error message "not enough arguments in call to method expression
Type.Method" instead of the old message "not enough arguments in call
to Type.Method".

Fixes #8385

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

While we're at it, move some misplaced comment blocks around.

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

It's easy for someone who wants a time bigger than any
valid time to reach for time.Unix(1<<63-1, 0), so it
makes sense to explicit say such value is not valid.

Fixes #10906 (again).

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

The Slicing-By-8 [1] algorithm has much performance improvements than
current approach. This patch only uses it for IEEE, which is the most
common case in practice.

There is the benchmark on Mac OS X 10.9:

benchmark                     old MB/s     new MB/s     speedup
BenchmarkIEEECrc1KB           349.40       353.03       1.01x
BenchmarkIEEECrc4KB           351.55       934.35       2.66x
BenchmarkCastagnoliCrc1KB     7037.58      7392.63      1.05x

This algorithm need 8K lookup table, so it's enabled only for block
larger than 4K.

We can see about 2.6x improvement for IEEE.

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

Fixes #11272.

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

Check that if a version is declared, for example
in '<?xml version="XX" ?>', version must be '1.0'.

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

When the scanner receives a non-whitespace character in stateEndTop,
it creates an error message and caches it to return on the next
transition. nextValue() uses the scanner to sub-scan for a value
inside a larger JSON structure. Since stateEndTop is triggered
*after* the ending byte, whatever character immediately follows the
sub-value gets pulled into the scanner's state machine as well.
Even though it is not used and doesn't cause an error, it does
cause the state machine to allocate an error that will never be used.

The fix is to probe the state machine with whitespace after
scanEndObject or scanEndArray to see if the next character would
result in a scanEnd state transition. If so, we can return right
away without processing the next character and avoid triggering
an allocation.

benchmark                       old ns/op     new ns/op     delta
BenchmarkCodeEncoder            17022194      16611336      -2.41%
BenchmarkCodeMarshal            18443250      18090144      -1.91%
BenchmarkCodeDecoder            61502053      61010936      -0.80%
BenchmarkCodeUnmarshal          61410829      60363605      -1.71%
BenchmarkCodeUnmarshalReuse     59124836      58361772      -1.29%
BenchmarkUnmarshalString        602           603           +0.17%
BenchmarkUnmarshalFloat64       535           537           +0.37%
BenchmarkUnmarshalInt64         482           482           +0.00%
BenchmarkIssue10335             1206          799           -33.75%
BenchmarkSkipValue              17605751      18355391      +4.26%
BenchmarkEncoderEncode          612           604           -1.31%

benchmark                  old MB/s     new MB/s     speedup
BenchmarkCodeEncoder       114.00       116.82       1.02x
BenchmarkCodeMarshal       105.21       107.27       1.02x
BenchmarkCodeDecoder       31.55        31.81        1.01x
BenchmarkCodeUnmarshal     31.60        32.15        1.02x
BenchmarkSkipValue         111.63       107.07       0.96x

benchmark                  old allocs     new allocs     delta
BenchmarkIssue10335        11             4              -63.64%
BenchmarkEncoderEncode     2              2              +0.00%

benchmark                  old bytes     new bytes     delta
BenchmarkIssue10335        376           272           -27.66%
BenchmarkEncoderEncode     40            40            +0.00%

Fixes #10335

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

Suggest running 'go help gopath' when the running 'go install .'
and the folder is outside of GOPATH.

Added link to 'https://golang.org/doc/code.html' in gopath help
for more information.

Example output:

% go install .
go install: no install location for directory f:\x\badmessage outside GOPATH
        please run 'go help gopath' for more information

% go help gopath
... SNIP ...
See https://golang.org/doc/code.html for an example.

Fixes #8457

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

Fixes #10734.

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

Check for errors when reading the headers following the pax headers.

Fixes #11169.

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

Return a meaningful message when a profile is empty.
Also rename "IO blocking" to "Network blocking",
currently only network blocking is captured.

Fixes #11098

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

There were two issues.
1. Delayed EvGoSysExit could have been emitted during TraceStart,
while it had not yet emitted EvGoInSyscall.
2. Delayed EvGoSysExit could have been emitted during next tracing session.

Fixes #10476
Fixes #11262

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

All the other error messages in this package are "lzw: etc".

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

In preparation for rename of cgocall_errno into cgocall and
asmcgocall_errno into asmcgocall in the fllowinng CL.
rsc requested CL 9387 to be split into two parts. This is first part.

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

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

Work-around issue #11265 and re-enable tests for Plan9.

Change-Id: I3aabb674a149b8eb936f948dd4cda5fd81454646
Reviewed-on: https://go-review.googlesource.com/11194
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Replace custom solution with new (internal) library call.

Change-Id: I53b26a1caf0684b9f5d8d749b10d9f3ba18a3001
Reviewed-on: https://go-review.googlesource.com/11193Reviewed-by: Damien Neil <dneil@google.com>

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

Change-Id: Ia9cbe3bfaa3e66c93d568d8beeed624b113d51a2
Reviewed-on: https://go-review.googlesource.com/11152Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This change will brake the build. The immediately following change
contains the necessary adjustments to make it work again. We're
doing this in two steps to expose the manual changes applied.

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

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

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

Updates #11241

Change-Id: I9639c4f66cf805a57b087c9f648d3918df105d86
Reviewed-on: https://go-review.googlesource.com/11034Reviewed-by: Robert Griesemer <gri@golang.org>

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

This fixes a hang during runtime.TestTraceStress.
It also fixes double-scan of stacks, which leads to
stack barrier installation failures.

Both of these have shown up as flaky failures on the dashboard.

Fixes #10941.

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

Adjust timestamps in TestABIChecking to make sure that the library and
executable are rebuilt when expected.

Change-Id: I3288c254ba8201b5b4255347b0cb056fa0908657
Reviewed-on: https://go-review.googlesource.com/11128Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Yves Junqueira <yves.junqueira@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

//go:systemstack means that the function must run on the system stack.

Add one use in runtime as a demonstration.

Fixes #9174.

Change-Id: I8d4a509cb313541426157da703f1c022e964ace4
Reviewed-on: https://go-review.googlesource.com/10840Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>

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

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

I updated some references to 6g, 6l and friends that I came across, as those
programs don't exist anymore. I also fixed some echos in make.rc to match other make.* scripts while I was there.

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

Corrected several issues:
 * RFC1951 section 3.2.7 dictates that it is okay for the HDist tree to have a
single code of zero bits. Furthermore, the behavior of the C zlib library
permits empty trees even when there are more than one codes.
 * RFC1951 section 3.2.5 shows that HLit codes 286 and 287 are invalid. Thus,
Go's implementation should choke on inputs using these codes.
 * RFC1951 section 3.2.5 and 3.2.7 are ambiguous about whether the number of
HDist codes can be greater than 30. The C zlib library (which is the canonical
reference implementation) performs this check here:
https://github.com/madler/zlib/blob/62d6112a7981ad7c34f3b43cffdf00d4662a4f25/inflate.c#L906

In addition, a number of test cases were added to the unit tests that exercises
these edge cases. The test cases listed in TestStreams will either fail or
succeed in a manner matching the behaviour of the C zlib version. Given that the
C zlib implementation is the reference for the world, Go's implementation should
match C zlib behaviour.

Fixes #11030

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

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

Also modified test/run.go to ignore messages prefixed <autogenerated>
because those cannot be described with "// ERROR ...", and backed out
patch from issue #9537 because it is no longer necessary.  The reasons
described in the 9537 discussion for why escape analysis cannot run
late no longer hold, happily.

Fixes #11053.

Change-Id: Icb14eccdf2e8cde3d0f8fb8a216b765400a96385
Reviewed-on: https://go-review.googlesource.com/11088Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David Chase <drchase@google.com>

This change reintroduces CL 8523. CL 8523 was reverted because
it broke darwin and netbsd builds. Now that this test is part
of "go tool dist test" command we could skip OSes that fail.

Updates #10360

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