I'm not sure how to write a test for this. The change in
behaviour is that if you somehow get a SIGBUS signal for an
address >= 0x1000, the program will now crash rather than
calling panic. As far as I know, on x86 GNU/Linux, the only
way to get a SIGBUS (rather than a SIGSEGV) is to set the
stack pointer to an invalid value.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7906045
Also:
- more consistenly use "xxx" statement rather than <code>xxx</code> statement
- fix/remove unnecessary links
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7821050
E.g conversions from numeric types to RawBytes are missing, what makes RawBytes unusable in some cases.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7783046
Will help people find the rules by searching the spec by
having a comment saying "missing return";
"terminating statement" does not evoke the rule to the
uninitiated.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7838044
The GIF89a spec says: "Each image must fit within the
boundaries of the Logical Screen, as defined in the
Logical Screen Descriptor." Also, do not accept
GIFs which have too much data for the image size.
R=nigeltao, jra, r
CC=bradfitz, golang-dev
https://golang.org/cl/7602045
On Darwin and FreeBSD, the mmap syscall return value is returned
unmodified. This means that the return value will either be a
valid address or a positive error number.
Also check return value from mmap in SysReserve - the callers of
SysReserve expect nil to be returned if the allocation failed.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7871043
Rather than just checking for ENOMEM, check for a return value of less
than 4096, so that we catch other errors such as EACCES and EINVAL.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7942043
Saves over 8KB of allocations per new connection.
benchmark old ns/op new ns/op delta
BenchmarkServerFakeConnNoKeepAlive 28777 24927 -13.38%
benchmark old allocs new allocs delta
BenchmarkServerFakeConnNoKeepAlive 52 46 -11.54%
benchmark old bytes new bytes delta
BenchmarkServerFakeConnNoKeepAlive 13716 5286 -61.46%
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/7799047
After the revert of revision 9ea9e7e6e0c8
the related revision 76ff7da868c6 must be reverted too.
Fixes#5102.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7961044
If a handler didn't consume all its Request.Body, child.go was
closing the socket while the host was still writing to it,
causing the child to send a RST and the host (at least nginx)
to send an empty response body.
Now, we tell the host we're done with the request/response
first, and then close our input pipe after consuming a bit of
it. Consuming the body fixes the problem, and flushing to the
host first to tell it that we're done increases the chance
that the host cuts off further data to us, meaning we won't
have much to consume.
No new tests, because this package is lacking in tests.
Tested by hand with nginx. See issue for testing details.
Fixes#4183
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7939045
Also adjust the implementation of applyRelocationsAMD64
so that the test added in CL 6848044 still passes.
R=golang-dev, minux.ma
CC=golang-dev
https://golang.org/cl/7686049
Only the net stuff remains as significant work in the "minor changes" section.
R=golang-dev, dave, elias.naur, rsc
CC=golang-dev
https://golang.org/cl/7933044
XOR key into data 128 bits at a time instead of 64 bits
and pipeline half of state loads. Rotate loop to allow
single-register indexing for state[i].
On a MacBookPro10,2 (Core i5):
benchmark old ns/op new ns/op delta
BenchmarkRC4_128 412 224 -45.63%
BenchmarkRC4_1K 3179 1613 -49.26%
BenchmarkRC4_8K 25223 12545 -50.26%
benchmark old MB/s new MB/s speedup
BenchmarkRC4_128 310.51 570.42 1.84x
BenchmarkRC4_1K 322.09 634.48 1.97x
BenchmarkRC4_8K 320.97 645.32 2.01x
For comparison, on the same machine, openssl 0.9.8r reports
its rc4 speed as somewhat under 350 MB/s for both 1K and 8K
(it is operating 64 bits at a time).
On an Intel Xeon E5520:
benchmark old ns/op new ns/op delta
BenchmarkRC4_128 418 259 -38.04%
BenchmarkRC4_1K 3200 1884 -41.12%
BenchmarkRC4_8K 25173 14529 -42.28%
benchmark old MB/s new MB/s speedup
BenchmarkRC4_128 306.04 492.48 1.61x
BenchmarkRC4_1K 319.93 543.26 1.70x
BenchmarkRC4_8K 321.61 557.20 1.73x
For comparison, on the same machine, openssl 1.0.1
reports its rc4 speed as 587 MB/s for 1K and 601 MB/s for 8K.
R=agl
CC=golang-dev
https://golang.org/cl/7865046
gcc generates only attr DW_AT_byte_size for DW_TAG_pointer_type of "void *",
but we used to also generate DW_AT_type pointing to imaginary unspecified
type "void", which confuses some gdb.
This change makes old Apple gdb 6.x (specifically, Apple version gdb-1515)
accepts our binary without issue like this:
(gdb) b 'main.main'
Die: DW_TAG_unspecified_type (abbrev = 10, offset = 47079)
has children: FALSE
attributes:
DW_AT_name (DW_FORM_string) string: "void"
Dwarf Error: Cannot find type of die [in module /Users/minux/go/go2.hg/bin/go]
Special thanks to Russ Cox for pointing out the problem in comment #6 of
CL 7891044.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7744051
CL 7504044 accidentally reverted part of CL 7891044 and 7552045, this CL
bring those part back.
R=golang-dev
TBR=rsc
CC=golang-dev
https://golang.org/cl/7950045
-- amd64 --
On a MacBookPro10,2 (Core i5):
benchmark old ns/op new ns/op delta
BenchmarkRC4_128 470 421 -10.43%
BenchmarkRC4_1K 3123 3275 +4.87%
BenchmarkRC4_8K 26351 25866 -1.84%
benchmark old MB/s new MB/s speedup
BenchmarkRC4_128 272.22 303.40 1.11x
BenchmarkRC4_1K 327.80 312.58 0.95x
BenchmarkRC4_8K 307.24 313.00 1.02x
For comparison, on the same machine, openssl 0.9.8r reports
its rc4 speed as somewhat under 350 MB/s for both 1K and 8K.
The Core i5 performance can be boosted another 20%, but only
by making the Xeon performance significantly slower.
On an Intel Xeon E5520:
benchmark old ns/op new ns/op delta
BenchmarkRC4_128 774 417 -46.12%
BenchmarkRC4_1K 6121 3200 -47.72%
BenchmarkRC4_8K 48394 25151 -48.03%
benchmark old MB/s new MB/s speedup
BenchmarkRC4_128 165.18 306.84 1.86x
BenchmarkRC4_1K 167.28 319.92 1.91x
BenchmarkRC4_8K 167.29 321.89 1.92x
For comparison, on the same machine, openssl 1.0.1
(which uses a different implementation than 0.9.8r)
reports its rc4 speed as 587 MB/s for 1K and 601 MB/s for 8K.
It is using SIMD instructions to do more in parallel.
So there's still some improvement to be had, but even so,
this is almost 2x faster than what it replaced.
-- 386 --
On a MacBookPro10,2 (Core i5):
benchmark old ns/op new ns/op delta
BenchmarkRC4_128 3491 421 -87.94%
BenchmarkRC4_1K 28063 3205 -88.58%
BenchmarkRC4_8K 220392 25228 -88.55%
benchmark old MB/s new MB/s speedup
BenchmarkRC4_128 36.66 303.81 8.29x
BenchmarkRC4_1K 36.49 319.42 8.75x
BenchmarkRC4_8K 36.73 320.90 8.74x
On an Intel Xeon E5520:
benchmark old ns/op new ns/op delta
BenchmarkRC4_128 2268 524 -76.90%
BenchmarkRC4_1K 18161 4137 -77.22%
BenchmarkRC4_8K 142396 32350 -77.28%
benchmark old MB/s new MB/s speedup
BenchmarkRC4_128 56.42 244.13 4.33x
BenchmarkRC4_1K 56.38 247.46 4.39x
BenchmarkRC4_8K 56.86 250.26 4.40x
R=agl
CC=golang-dev
https://golang.org/cl/7547050
Fixes#5061.
Current code relies on the fact that fd's are automatically removed from epoll set when closed. However, it is not true. Underlying file description is removed from epoll set only when *all* fd's referring to it are closed.
There are 2 bad consequences:
1. Kernel delivers notifications on already closed fd's.
2. The following sequence of events leads to error:
- add fd1 to epoll
- dup fd1 = fd2
- close fd1 (not removed from epoll since we've dup'ed the fd)
- dup fd2 = fd1 (get the same fd as fd1)
- add fd1 to epoll = EEXIST
So, if fd can be potentially dup'ed of fork'ed, it's necessary to explicitly remove the fd from epoll set.
R=golang-dev, bradfitz, dave
CC=golang-dev
https://golang.org/cl/7870043
Add missing CLOSUREVAR in switch.
Mark MAKE, string conversion nodes as impossible.
Control statements do not need instrumentation.
Instrument COM and LROT nodes.
Instrument map length.
Update #4228
R=dvyukov, golang-dev
CC=golang-dev
https://golang.org/cl/7504047
