Brad Fitzpatrick [Wed, 14 Oct 2015 20:41:36 +0000 (20:41 +0000)]
net/http: enable automatic HTTP/2 if TLSNextProto is nil
This enables HTTP/2 by default (for https only) if the user didn't
configure anything in their NPN/ALPN map. If they're using SPDY or an
alternate http2 or a newer http2 from x/net/http2, we do nothing
and don't use the standard library's vendored copy of x/net/http2.
David Glasser [Wed, 14 Oct 2015 21:25:00 +0000 (14:25 -0700)]
net/http: don't hang if RemoteAddr() blocks
The PROXY protocol is supported by several proxy servers such as haproxy
and Amazon ELB. This protocol allows services running behind a proxy to
learn the remote address of the actual client connecting to the proxy,
by including a single textual line at the beginning of the TCP
connection.
http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt
There are several Go libraries for this protocol (such as
https://github.com/armon/go-proxyproto), which operate by wrapping a
net.Conn with an implementation whose RemoteAddr method reads the
protocol line before returning. This means that RemoteAddr is a blocking
call.
Before this change, http.Serve called RemoteAddr from the main Accepting
goroutine, not from the per-connection goroutine. This meant that it
would not Accept another connection until RemoteAddr returned, which is
not appropriate if RemoteAddr needs to do a blocking read from the
socket first.
Raul Silvera [Wed, 14 Oct 2015 02:49:40 +0000 (19:49 -0700)]
runtime: Reduce testing for fastlog2 implementation
The current fastlog2 testing checks all 64M values in the domain of
interest, which is too much for platforms with no native floating point.
Reduce testing under testing.Short() to speed up builds for those platforms.
Related to #12620
Change-Id: Ie5dcd408724ba91c3b3fcf9ba0dddedb34706cd1
Reviewed-on: https://go-review.googlesource.com/15830 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Joel Sing <jsing@google.com> Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Hyang-Ah Hana Kim [Tue, 13 Oct 2015 17:58:11 +0000 (13:58 -0400)]
misc/cgo/testcshared: use -pie for android-L.
Also, handle the case where 'read' returns EINVAL instead of EBADF
when the descriptor is not ready. (android 4.4.4/cyanogenmod, nexus7)
Change-Id: I56c5949d27303d44a4fd0de38951b85e20cef167
Reviewed-on: https://go-review.googlesource.com/15810 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Tue, 13 Oct 2015 17:05:13 +0000 (10:05 -0700)]
misc/cgo/test: fix go vet warnings
Fixes these warnings from go vet:
buildid_linux.go:25: no formatting directive in Fatalf call
callback.go:180: arg pc[i] for printf verb %p of wrong type: uintptr
env.go:34: possible misuse of unsafe.Pointer
issue7665.go:22: possible misuse of unsafe.Pointer
Change-Id: I83811b9c10c617139713a626b4a34ab05564d4fe
Reviewed-on: https://go-review.googlesource.com/15802 Reviewed-by: David Crawshaw <crawshaw@golang.org>
Burcu Dogan [Mon, 12 Oct 2015 08:02:51 +0000 (01:02 -0700)]
cmd/go: always log dynamic import errors
There is no easy way to understand what user intent was and whether
they wanted to use a dynamic import or not.
If we skip logging such errors, it breaks common use cases such as
https://golang.org/issue/12810.
It's a better approach to expose the underlying mechanism and
be more verbose with the error messages.
Fixes #12810.
Change-Id: I7e922c9e848382690d9d9b006d7046e6cf93223b
Reviewed-on: https://go-review.googlesource.com/15756 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
Brad Fitzpatrick [Mon, 12 Oct 2015 20:41:40 +0000 (20:41 +0000)]
net/http: export the "new" error codes from RFC 6585
These were proposed in the RFC over three years ago, then proposed to
be added to Go in https://codereview.appspot.com/7678043/ 2 years and
7 months ago, and the spec hasn't been updated or retracted the whole
time.
Time to export them.
Of note, HTTP/2 uses code 431 (Request Header Fields Too Large).
Updates #12843
Change-Id: I78c2fed5fab9540a98e845ace73f21c430a48809
Reviewed-on: https://go-review.googlesource.com/15732 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Dave Cheney [Sat, 10 Oct 2015 03:21:42 +0000 (14:21 +1100)]
net/url: make *url.Error implement net.Error
Fixes #12866
net/http.Client returns some errors wrapped in a *url.Error. To avoid
the requirement to unwrap these errors to determine if the cause was
temporary or a timeout, make *url.Error implement net.Error directly.
Joe Tsai [Tue, 22 Sep 2015 08:33:11 +0000 (01:33 -0700)]
compress/flate: deprecate ReadError and WriteError
A vast majority of the time, ReadError isn't even returned during
IO operations. Instead, an unwrapped error will be returned because
of the ReadByte call on L705. Because DEFLATE streams are primarily
compressed and require byte for byte Huffman decoding, most of the
data read from a data stream will go through ReadByte.
Although this is technically an API change, any user reliant on
this error would not have worked properly anyways due to the fact
that most IO error are not wrapped. We might as well deprecate
ReadError. It is useless and actually makes clients that do
depend on catching IO errors more difficult.
Fixes #11856
Fixes #12724
Change-Id: Ib5fec5ae215e977c4e85de5701ce6a473d400af8
Reviewed-on: https://go-review.googlesource.com/14834 Reviewed-by: Nigel Tao <nigeltao@golang.org>
Ian Lance Taylor [Fri, 9 Oct 2015 20:02:25 +0000 (13:02 -0700)]
cmd/link: remove -W option
The -W option has not worked since Go 1.3. It is not documented. When
it did work, it generated useful output, but it was for human viewing;
there was no reason to write a script that passes the -W option, so it's
unlikely that anybody is using it today.
Nodir Turakulov [Fri, 9 Oct 2015 18:59:58 +0000 (11:59 -0700)]
cmd/go: print all warnings to stderr
All warnings in cmd/go are printed using fmt.Fprintf(os.Stderr...)
except one in test.go which is printed using log.Printf.
This is a minor inconsistency.
Austin Clements [Mon, 5 Oct 2015 03:56:11 +0000 (20:56 -0700)]
runtime: assist before allocating
Currently, when the mutator allocates, the runtime first allocates the
memory and then, if that G has done "enough" allocation, the runtime
checks whether the G has assist debt to pay off and, if so, pays it
off. This approach leads to under-assisting, where a G can allocate a
large region (or many small regions) before paying for it, or can even
exit with outstanding debt.
This commit flips this around so that a G always acquires enough
credit for an allocation before it can perform that allocation. We
continue to amortize the cost of assists by requiring that they
over-assist when triggered to build up credit for many allocations.
Austin Clements [Mon, 5 Oct 2015 03:16:57 +0000 (20:16 -0700)]
runtime: directly track GC assist balance
Currently we track the per-G GC assist balance as two monotonically
increasing values: the bytes allocated by the G this cycle (gcalloc)
and the scan work performed by the G this cycle (gcscanwork). The
assist balance is hence assistRatio*gcalloc - gcscanwork.
This works, but has two important downsides:
1) It requires floating-point math to figure out if a G is in debt or
not. This makes it inappropriate to check for assist debt in the
hot path of mallocgc, so we only do this when a G allocates a new
span. As a result, Gs can operate "in the red", leading to
under-assist and extended GC cycle length.
2) Revising the assist ratio during a GC cycle can lead to an "assist
burst". If you think of plotting the scan work performed versus
heaps size, the assist ratio controls the slope of this line.
However, in the current system, the target line always passes
through 0 at the heap size that triggered GC, so if the runtime
increases the assist ratio, there has to be a potentially large
assist to jump from the current amount of scan work up to the new
target scan work for the current heap size.
This commit replaces this approach with directly tracking the GC
assist balance in terms of allocation credit bytes. Allocating N bytes
simply decreases this by N and assisting raises it by the amount of
scan work performed divided by the assist ratio (to get back to
bytes).
This will make it cheap to figure out if a G is in debt, which will
let us efficiently check if an assist is necessary *before* performing
an allocation and hence keep Gs "in the black".
This also fixes assist bursts because the assist ratio is now in terms
of *remaining* work, rather than work from the beginning of the GC
cycle. Hence, the plot of scan work versus heap size becomes
continuous: we can revise the slope, but this slope always starts from
where we are right now, rather than where we were at the beginning of
the cycle.
Change-Id: Ia821c5f07f8a433e8da7f195b52adfedd58bdf2c
Reviewed-on: https://go-review.googlesource.com/15408 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Thu, 8 Oct 2015 05:37:15 +0000 (22:37 -0700)]
runtime: ensure minimum heap distance via heap goal
Currently we ensure a minimum heap distance of 1MB when computing the
assist ratio. Rather than enforcing this minimum on the heap distance,
it makes more sense to enforce that the heap goal itself is at least
1MB over the live heap size at the beginning of GC. Currently the two
approaches are semantically equivalent, but this will let us switch to
basing the assist ratio on current heap distance rather than the
initial heap distance, since we can't enforce this minimum on the
current heap distance (the GC may never finish because the goal posts
will always be 1MB away).
Change-Id: I0027b1c26a41a0152b01e5b67bdb1140d43ee903
Reviewed-on: https://go-review.googlesource.com/15604 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Mon, 5 Oct 2015 03:00:01 +0000 (23:00 -0400)]
runtime: update gcController.scanWork regularly
Currently, gcController.scanWork is updated as lazily as possible
since it is only read at the end of the GC cycle. We're about to read
it during the GC cycle to improve the assist ratio revisions, so
modify gcDrain* to regularly flush to gcController.scanWork in much
the same way as we regularly flush to gcController.bgScanCredit.
One consequence of this is that it's difficult to keep gcw.scanWork
monotonic, so we give up on that and simply return the amount of scan
work done by gcDrainN rather than calculating it in the caller.
Change-Id: I7b50acdc39602f843eed0b5c6d2dacd7e762b81d
Reviewed-on: https://go-review.googlesource.com/15407 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Mon, 5 Oct 2015 02:47:27 +0000 (22:47 -0400)]
runtime: control background scan credit flushing with flag
Currently callers of gcDrain control whether it flushes scan work
credit to gcController.bgScanCredit by passing a value other than -1
for the flush threshold. Shortly we're going to make this always flush
scan work to gcController.scanWork and optionally also flush scan work
to gcController.bgScanCredit. This will be much easier if the flush
threshold is simply a constant (which it is in practice) and callers
merely control whether or not the flush includes the background
credit. Hence, replace the flush threshold argument with a flag.
Change-Id: Ia27db17de8a3f1e462a5d7137d4b5dc72f99a04e
Reviewed-on: https://go-review.googlesource.com/15406 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Mon, 5 Oct 2015 02:42:43 +0000 (22:42 -0400)]
runtime: consolidate gcDrain and gcDrainUntilPreempt
These functions were nearly identical. Consolidate them by adding a
flags argument. In addition to cleaning up this code, this makes
further changes that affect both functions easier.
Change-Id: I6ec5c947603bbbd3ff4040113b2fbc240e99745f
Reviewed-on: https://go-review.googlesource.com/15405 Reviewed-by: Rick Hudson <rlh@golang.org>
mpl [Sun, 4 Oct 2015 21:32:26 +0000 (23:32 +0200)]
mime/multipart: fix peekBufferSeparatorIndex edge case
The case fixed by this change happens when, in func (pr partReader)
Read, the Peek happens to read so that peek looks like:
"somedata\r\n--Boundary\r"
peekBufferSeparatorIndex was returning (-1, false) because it didn't
find the trailing '\n'.
This was wrong because:
1) It didn't match the documentation: as "\r\n--Boundary" was found, it
should return the index of that pattern, not -1.
2) It lead to an nCopy cut such as:
"somedata\r| |\n--Boundary\r" instead of "somedata| |\r\n--Boundary\r"
which made the subsequent Read miss the boundary, and eventually end
with a "return 0, io.ErrUnexpectedEOF" case, as reported in:
obj.ProgInfo is a field inside obj.Prog, which is currently 320 bytes
on 64bit platforms. By moving the Flags field below the other fields
the size of obj.Prog drops into the 288 byte size class, a saving of
32 bytes per value allocated on the heap.
Matthew Dempsky [Thu, 8 Oct 2015 19:43:57 +0000 (12:43 -0700)]
syscall: fix vet warning in UnixRights
Change-Id: Ic19c94fe0af55e17f6c2fcfd36085ccb1584da6f
Reviewed-on: https://go-review.googlesource.com/15608 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Ian Lance Taylor [Thu, 8 Oct 2015 17:22:50 +0000 (10:22 -0700)]
cmd/link: pass -Wl,-z,nodelete when creating an ELF shared library
Go shared libraries do not support dlclose, and there is no likelihood
that they will suppose dlclose in the future. Set the DF_1_NODELETE
flag to tell the dynamic linker to not attempt to remove them from
memory. This makes the shared library act as though every call to
dlopen passed the RTLD_NODELETE flag.
Fixes #12582.
Update #11100.
Update #12873.
Change-Id: Id4b6e90a1b54e2e6fc8355b5fb22c5978fc762b4
Reviewed-on: https://go-review.googlesource.com/15605 Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Keith Randall [Mon, 31 Aug 2015 23:26:12 +0000 (16:26 -0700)]
runtime: make aeshash more DOS-proof
Improve the aeshash implementation to make it harder to engineer collisions.
1) Scramble the seed before xoring with the input string. This
makes it harder to cancel known portions of the seed (like the size)
because it mixes the per-table seed into those other parts.
2) Use table-dependent seeds for all stripes when hashing >16 byte strings.
For small strings this change uses 4 aesenc ops instead of 3, so it
is somewhat slower. The first two can run in parallel, though, so
it isn't 33% slower.
but it turns out that it's necessary to avoid the GC seeing partially written
pointers.
It's of course possible to be more sophisticated (using ldp/stp to move 16
bytes at a time in the core loop and unrolling the tail copying loops being
the obvious ideas) but I wanted something simple and (reasonably) obviously
correct.
Didier Spezia [Wed, 7 Oct 2015 22:25:25 +0000 (22:25 +0000)]
cmd/compile: fix some C to Go translation leftovers
Following the C to Go translation, some useless variables
were left in the code. In fmt.go, this was harmless.
In lex.go, it broke the error message related to
non-canonical import paths.
Fix it, and remove the useless variables.
The added test case is ignored in the go/types tests, since
the behavior of the non-canonical import path check seems
to be different.
Fixes #11362
Change-Id: Ic9129139ede90357dc79ebf167af638cf44536fa
Reviewed-on: https://go-review.googlesource.com/15580 Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com> Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Charlie Dorian [Wed, 7 Oct 2015 03:16:47 +0000 (23:16 -0400)]
math/cmplx: make error tolerance test function of expected value
Copy math package CL 12230 to cmplx package.
Change-Id: I3345b782b84b5b98e2b6a60d8774c7e7cede2891
Reviewed-on: https://go-review.googlesource.com/15500 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Joe Tsai [Thu, 1 Oct 2015 08:04:24 +0000 (01:04 -0700)]
archive/tar: fix numeric overflow issues in readGNUSparseMap0x1
Motivation:
* The logic to verify the numEntries can overflow and incorrectly
pass, allowing a malicious file to allocate arbitrary memory.
* The use of strconv.ParseInt does not set the integer precision
to 64bit, causing this code to work incorrectly on 32bit machines.
Joe Tsai [Tue, 6 Oct 2015 08:04:18 +0000 (01:04 -0700)]
archive/tar: add missing error checks to Reader.Next
A recursive call to Reader.Next did not check the error before
trying to use the result, leading to a nil pointer panic.
This specific CL addresses the immediate issue, which is the panic,
but does not solve the root issue, which is due to an integer
overflow in the base-256 parser.
Michael Hudson-Doyle [Wed, 23 Sep 2015 03:46:00 +0000 (15:46 +1200)]
cmd/link: set the ELF headers of ARM executables that use cgo correctly
It is generally expected that the ELF flags of a dynamically linked executable
and the libraries it links against match. Go's linker currently always produces
executables with flags that do not declare a float abi (hard, soft) at all, but
when cgo is involved it is unlikely that this matches the system libraries
being linked against -- really the decision about ABI is made by the C compiler
during the invocation of cgo.
This change is basically a port of the code from binutils that parses the
".ARM.attributes" section to check for the tag that declares that the code is
built for the hard-float ABI.
Fixes #7094
Change-Id: I737c8f3b5ed4af545cfc3e86722d03eb83083402
Reviewed-on: https://go-review.googlesource.com/14860
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Minux Ma <minux@golang.org>
Shenghou Ma [Mon, 14 Sep 2015 04:48:02 +0000 (00:48 -0400)]
cmd/cgo: update docs refering to 6g and 6l
Change-Id: Id6cb5e3d40e8a2ded6359aa7fcdc012861cc3994
Reviewed-on: https://go-review.googlesource.com/14545 Reviewed-by: Andrew Gerrand <adg@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Joe Tsai [Thu, 1 Oct 2015 09:59:49 +0000 (02:59 -0700)]
archive/tar: expand abilities of TestReader
Motivation:
* There are an increasing number of "one-off" corrupt files added
to make sure that package does not succeed or crash on them.
Instead, allow for the test to specify the error that is expected
to occur (if any).
* Also, fold in the logic to check the MD5 checksum into this
function.
The following tests are being removed:
* TestIncrementalRead: Done by TestReader by using io.CopyBuffer
with a buffer of 8. This achieves the same behavior as this test.
* TestSparseEndToEnd: Since TestReader checks the MD5 checksums
if the input corpus provides them, then this is redundant.
* TestSparseIncrementalRead: Redundant for the same reasons that
TestIncrementalRead is now redundant
* TestNegativeHdrSize: Added to TestReader corpus
* TestIssue10968: Added to TestReader corpus
* TestIssue11169: Added to TestReader corpus
With this change, code coverage did not change: 85.3%
Change-Id: I8550d48657d4dbb8f47dfc3dc280758ef73b47ec
Reviewed-on: https://go-review.googlesource.com/15176 Reviewed-by: Andrew Gerrand <adg@golang.org>
Katrina Owen [Tue, 6 Oct 2015 03:15:23 +0000 (21:15 -0600)]
doc: fix typo in contributing guide
Change-Id: I6d9a8886cccf1c396ea2dbc659c5bf7548179751
Reviewed-on: https://go-review.googlesource.com/15435 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Joe Tsai [Thu, 1 Oct 2015 22:21:40 +0000 (15:21 -0700)]
io: simplify documentation for ByteReader
Let C be whether c valid
Let E be whether err is non-nil
The old comment explicitly says that (~C → E). However, that does call
into question whether (E → ~C), which causes doubts for users.
Without a comment at all, it is obvious that only (E ↔ ~C) makes sense.
Fixes #11308
Change-Id: I5a7d51ceb509057eccca91f57a7e48c9d1c6d112
Reviewed-on: https://go-review.googlesource.com/15256 Reviewed-by: Andrew Gerrand <adg@golang.org>
Joe Tsai [Thu, 1 Oct 2015 22:09:11 +0000 (15:09 -0700)]
io: clarify documentation for Seeker
The later part of the docstring simply talks about "offset" but does
not disambiguate what it is relative to. For both the return value
and valid offsets to seek to, it only makes sense in the context of
"offset relative to origin of file".
Fixes #11877
Change-Id: Ic238a407cf8e8fdd64991d98a6584cdc8a51cd6b
Reviewed-on: https://go-review.googlesource.com/15257 Reviewed-by: Andrew Gerrand <adg@golang.org>
Ian Lance Taylor [Mon, 5 Oct 2015 18:05:10 +0000 (11:05 -0700)]
net: remove imports of strconv
The net package already has support for limited uses of the strconv
package. Despite this, a few uses of strconv have crept in over time.
Remove them and use the existing net support instead.
Change-Id: Icdb4bdaa8e1197f1119a96cddcf548ed4a551b74
Reviewed-on: https://go-review.googlesource.com/15400
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Didier Spezia [Sat, 3 Oct 2015 15:50:45 +0000 (15:50 +0000)]
cmd/cgo: fix panic on references to non-existing C types
cgo panics in Package.rewriteRef for:
var a = C.enum_test(1)
or
p := new(C.enum_test)
when the corresponding enum type is not defined.
Check nil values for Type fields and issue a proper
error instead.
Fixes #11097
Updates #12160
Change-Id: I5821d29097ef0a36076ec5273125b09846c7d832
Reviewed-on: https://go-review.googlesource.com/15264 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Kenny Grant [Sun, 27 Sep 2015 13:53:18 +0000 (14:53 +0100)]
net/http: add response body to 413 and 400 errors
The existing serve() method returns a zero-length response body when
it encounters an error, which results in a blank page and no visible
error in browsers.
This change sends a response body explaining the error for display in browsers.
The current heap sampling introduces some bias that interferes
with unsampling, producing unexpected heap profiles.
The solution is to use a Poisson process to generate the
sampling points, using the formulas described at
https://en.wikipedia.org/wiki/Poisson_process
This fixes #12620
Change-Id: If2400809ed3c41de504dd6cff06be14e476ff96c
Reviewed-on: https://go-review.googlesource.com/14590 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Turns out the summary information for the ... args was
already correctly computed, all that lacked was to make
use of it and correct tests that documented our prior
deficiencies.
Shenghou Ma [Thu, 1 Oct 2015 01:27:30 +0000 (21:27 -0400)]
cmd/go: remove the bootstrap with make.bash error message
The runtime/zgoos_$GOOS.go and runtime/zgoarch_$GOARCH.go files
are in the repository now, so the message is actually incorrect
(running make.bash won't generate those). The reason is probably
wrong $GOROOT.
Change-Id: I8dc125594c52d666eca91fd5af48b60d12d599b8
Reviewed-on: https://go-review.googlesource.com/15221 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Shenghou Ma [Mon, 14 Sep 2015 05:28:57 +0000 (01:28 -0400)]
cmd/yacc: fix copying action code when line comment is disabled
Fixes #12601.
Change-Id: I0be69ffe9ba19934aaef1651845c725708db77de
Reviewed-on: https://go-review.googlesource.com/14546 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Didier Spezia [Sat, 3 Oct 2015 17:42:52 +0000 (17:42 +0000)]
cmd/cgo: remove support for CGOPKGPATH
CGOPKGPATH variable was undocumented, but it is not needed anymore.
It was used before the existence of the go tool to tell cgo the full
path of the package that it was building, which in turn set the name
of the shared library that cgo expected to load back when cgo used
shared libraries. CGOPKGPATH no longer does anything useful;
it just affects the comments in the generated header file.
Brad Fitzpatrick [Sat, 3 Oct 2015 16:35:40 +0000 (09:35 -0700)]
cmd/compile/internal/gc: fix the build
Commit acc90c5 passed the trybots, lingered for weeks, and in the
meantime the type of this variable changed to a bool. I didn't rebase
and re-run the trybots before submitting.
acanino [Sat, 22 Aug 2015 02:24:20 +0000 (22:24 -0400)]
cmd/compile: Fix `internal compiler: getinarg: not a func` when returning invalid interface.
Internal error arose from calling methodfunc on a invalid interface
field during the implements check. int obviously isn't a function,
and errors on getinarg...
for im := iface.Type; im != nil; im = im.Down {
imtype = methodfunc(im.Type, nil)
// ...
}
Fix handles the internal compiler error, but does not throw an
additional error, i.e. the following code will error on the I
interface, but type A will pass the implements check since
'Read(string) string' is implemented and 'int' is skipped
Austin Clements [Fri, 2 Oct 2015 22:17:54 +0000 (18:17 -0400)]
runtime: use 4 byte writes in amd64p32 memmove/memclr
Currently, amd64p32's memmove and memclr use 8 byte writes as much as
possible and 1 byte writes for the tail of the object. However, if an
object ends with a 4 byte pointer at an 8 byte aligned offset, this
may copy/zero the pointer field one byte at a time, allowing the
garbage collector to observe a partially copied pointer.
Fix this by using 4 byte writes instead of 8 byte writes.
runtime: adjust huge page flags only on huge page granularity
This fixes an issue where the runtime panics with "out of memory" or
"cannot allocate memory" even though there's ample memory by reducing
the number of memory mappings created by the memory allocator.
Commit 7e1b61c worked around issue #8832 where Linux's transparent
huge page support could dramatically increase the RSS of a Go process
by setting the MADV_NOHUGEPAGE flag on any regions of pages released
to the OS with MADV_DONTNEED. This had the side effect of also
increasing the number of VMAs (memory mappings) in a Go address space
because a separate VMA is needed for every region of the virtual
address space with different flags. Unfortunately, by default, Linux
limits the number of VMAs in an address space to 65530, and a large
heap can quickly reach this limit when the runtime starts scavenging
memory.
This commit dramatically reduces the number of VMAs. It does this
primarily by only adjusting the huge page flag at huge page
granularity. With this change, on amd64, even a pessimal heap that
alternates between MADV_NOHUGEPAGE and MADV_HUGEPAGE must reach 128GB
to reach the VMA limit. Because of this rounding to huge page
granularity, this change is also careful to leave large used and
unused regions huge page-enabled.
This change reduces the maximum number of VMAs during the runtime
benchmarks with GODEBUG=scavenge=1 from 692 to 49.
Fixes #12233.
Change-Id: Ic397776d042f20d53783a1cacf122e2e2db00584
Reviewed-on: https://go-review.googlesource.com/15191 Reviewed-by: Keith Randall <khr@golang.org>
In general, finishsweep_m must block until any spans that are
concurrently being swept have been swept. It accomplishes this by
looping over all spans, which, as in the previous commit, takes
~1ms/heap GB. Unfortunately, we do this during the STW sweep
termination phase, so multi-gigabyte heaps can push our STW time past
10ms.
However, there's no need to do this wait if the world is stopped
because, in effect, stopping the world already had to wait for
anything that was sweeping (and if it didn't, the wait in
finishsweep_m would deadlock). Hence, we can simply skip this loop if
the world is stopped, such as during sweep termination. In fact,
currently all calls to finishsweep_m are STW, but this hasn't always
been the case and may not be the case in the future, so we keep the
logic around.
For 24GB heaps, this reduces max pause time by 75% relative to tip and
by 90% relative to Go 1.5. Notably, all pauses are now well under
10ms. Here are the results for the garbage benchmark:
------------- max pause ------------
Heap Procs after change before change 1.5.1
24GB 12 3.8ms 16ms 37ms
24GB 4 3.7ms 16ms 37ms
4GB 4 3.7ms 3ms 6.9ms
In the 4GB/4P case, it seems the "before change" run got lucky: the
max went up, but the 99%ile pause time went down from 3ms to 2.04ms.
In order to compute the sweep ratio, the runtime needs to know how
many pages belong to spans in state _MSpanInUse. Currently it finds
this out by looping over all spans during mark termination. However,
this takes ~1ms/heap GB, so multi-gigabyte heaps can quickly push our
STW time past 10ms.
Replace the loop with an actively maintained count of in-use pages.
For multi-gigabyte heaps, this reduces max mark termination pause time
by 75%–90% relative to tip and by 85%–95% relative to Go 1.5.1. This
shifts the longest pause time for large heaps to the sweep termination
phase, so it only slightly decreases max pause time, though it roughly
halves mean pause time. Here are the results for the garbage
benchmark:
---- max mark termination pause ----
Heap Procs after change before change 1.5.1
24GB 12 1.9ms 18ms 37ms
24GB 4 3.7ms 18ms 37ms
4GB 4 920µs 3.8ms 6.9ms
runtime: scan objects with finalizers concurrently
This reduces pause time by ~25% relative to tip and by ~50% relative
to Go 1.5.1.
Currently one of the steps of STW mark termination is to loop (in
parallel) over all spans to find objects with finalizers in order to
mark all objects reachable from these objects and to treat the
finalizer special as a root. Unfortunately, even if there are no
finalizers at all, this loop takes roughly 1 ms/heap GB/core, so
multi-gigabyte heaps can quickly push our STW time past 10ms.
Fix this by moving this scan from mark termination to concurrent scan,
where it can run in parallel with mutators. The loop itself could also
be optimized, but this cost is small compared to concurrent marking.
Making this scan concurrent introduces two complications:
1) The scan currently walks the specials list of each span without
locking it, which is safe only with the world stopped. We fix this by
speculatively checking if a span has any specials (the vast majority
won't) and then locking the specials list only if there are specials
to check.
2) An object can have a finalizer set after concurrent scan, in which
case it won't have been marked appropriately by concurrent scan. If
the finalizer is a closure and is only reachable from the special, it
could be swept before it is run. Likewise, if the object is not marked
yet when the finalizer is set and then becomes unreachable before it
is marked, other objects reachable only from it may be swept before
the finalizer function is run. We fix this issue by making
addfinalizer ensure the same marking invariants as markroot does.
For multi-gigabyte heaps, this reduces max pause time by 20%–30%
relative to tip (depending on GOMAXPROCS) and by ~50% relative to Go
1.5.1 (where this loop was neither concurrent nor parallel). Here are
the results for the garbage benchmark:
Robert Griesemer [Fri, 2 Oct 2015 17:55:27 +0000 (10:55 -0700)]
readme: emphasize issue tracker is for bugs/proposals
Removed direct link to issue tracker in the README - it makes it too
easy to use it for a question - and it's abused multiple times a day
for questions. It's easy enough to find it if there's a real issue
to report.
Added sentence to point people at golang-nuts and the new forum.
Michael Hudson-Doyle [Tue, 22 Sep 2015 10:35:52 +0000 (22:35 +1200)]
runtime: adjust the ppc64x memmove and memclr to copy by word as much as it can
Issue #12552 can happen on ppc64 too, although much less frequently in my
testing. I'm fairly sure this fixes it (2 out of 200 runs of oracle.test failed
without this change and 0 of 200 failed with it). It's also a lot faster for
large moves/clears:
runtime: drop sigfwd from signal forwarding unsupported platforms
This change splits signal_unix.go into signal_unix.go and
signal2_unix.go and removes the fake symbol sigfwd from signal
forwarding unsupported platforms for clarification purpose.
Change-Id: I205eab5cf1930fda8a68659b35cfa9f3a0e67ca6
Reviewed-on: https://go-review.googlesource.com/12062 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Burcu Dogan [Thu, 1 Oct 2015 19:01:50 +0000 (15:01 -0400)]
net: make /etc/hosts lookups case-insensitive
The native Go host resolver was behaving differently than libc
and the entries in the /etc/hosts were handled in a case sensitive
way. In order to be compatible with libc's resolver, /etc/hosts
lookups must be case-insensitive.