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>
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/10923
Reviewed-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/10922
Reviewed-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/11083
Reviewed-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/11273
Reviewed-by: David Symonds <dsymonds@golang.org>
This is a documentation fix that reflects the current reality.
Fixes#9673.
Change-Id: Ie436b277dfd1b68b13c67813d29c238d2c23b820
Reviewed-on: https://go-review.googlesource.com/11221
Reviewed-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/11123
Reviewed-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/10926
Reviewed-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/11247
Reviewed-by: Ian Lance Taylor <iant@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/11064
Reviewed-by: Nigel Tao <nigeltao@golang.org>
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/11063
Reviewed-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/10590
Reviewed-by: Austin Clements <austin@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/2193
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/10266
Reviewed-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/1863
Reviewed-by: Russ Cox <rsc@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/8961
Reviewed-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/9074
Reviewed-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/9258
Reviewed-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/11031
Reviewed-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/11243
Reviewed-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#10476Fixes#11262
Change-Id: Iab68eb31cf38eb6eb6eee427f49c5ca0865a8c64
Reviewed-on: https://go-review.googlesource.com/9132
Reviewed-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/11228
Reviewed-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/11166
Reviewed-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>
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/11151
Reviewed-by: Alan Donovan <adonovan@google.com>
