We see timeouts in these tests on some platforms,
but not on the others. The hypothesis is that
the problematic platforms are slow uniprocessors.
Stack traces do not suggest that the process
is completely hang, and it is able to schedule
the alarm goroutine. And if it actually hangs,
we still will be able to detect that.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/12253043
With dup3, we can avoid an extra system call on some machines
while holding syscall.ForkLock. Currently we have to
syscall.Dup + syscall.CloseOnExec.
On machines with Linux and a new enough kernel, this can just
be dup3.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/12170045
(Replacement for CL 11884043.)
1) Explain a[i] and a[i:j] where a is of type *A as
shortcut for (*a)[i] and (*a)[i:j], respectively.
2) Together with 1), because len() of nil slices is
well defined, there's no need to special case nil
operands anymore.
3) The result of indexing or slicing a constant string
is always a non-constant byte or string value.
4) The result of slicing an untyped string is a value
of type string.
5) If the operand of a valid slice a[i:j] is nil (i, j
must be 0 for it to be valid - this already follows
from the in-range rules), the result is a nil slice.
Fixes#4913.
Fixes#5951.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/12198043
Preemption during the software floating point code
could cause m (R9) to change, so that when the
original registers were restored at the end of the
floating point handler, the changed and correct m
would be replaced by the old and incorrect m.
TBR=dvyukov
CC=golang-dev
https://golang.org/cl/11883045
Operations on int64 are very stack consuming with 5c.
Fixes netbsd/arm build.
Before: TEXT runtime.timediv+0(SB),7,$52-16
After: TEXT runtime.timediv+0(SB),7,$44-16
The stack usage is unchanged on 386:
TEXT runtime.timediv+0(SB),7,$8-16
R=golang-dev, dvyukov, bradfitz
CC=golang-dev
https://golang.org/cl/12182044
CL submitted prematurely by mistake.
««« original CL description
spec: clarify index and selector expressions
1) Explain a[i] and a[i:j] where a is of type *A as
shortcut for (*a)[i] and (*a)[i:j], respectively.
2) Together with 1), because len() of nil slices is
well defined, there's no need to special case nil
operands anymore.
3) The result of indexing or slicing a constant string
is always a non-constant byte or string value.
4) The result of slicing an untyped string is a value
of type string.
5) If the operand of a valid slice a[i:j] is nil (i, j
must be 0 for it to be valid - this already follows
from the in-range rules), the result is a nil slice.
Fixes#4913.
Fixes#5951.
R=rsc, r, iant, ken
CC=golang-dev
https://golang.org/cl/11884043
»»»
R=r
CC=golang-dev
https://golang.org/cl/12170046
1) Explain a[i] and a[i:j] where a is of type *A as
shortcut for (*a)[i] and (*a)[i:j], respectively.
2) Together with 1), because len() of nil slices is
well defined, there's no need to special case nil
operands anymore.
3) The result of indexing or slicing a constant string
is always a non-constant byte or string value.
4) The result of slicing an untyped string is a value
of type string.
5) If the operand of a valid slice a[i:j] is nil (i, j
must be 0 for it to be valid - this already follows
from the in-range rules), the result is a nil slice.
Fixes#4913.
Fixes#5951.
R=rsc, r, iant, ken
CC=golang-dev
https://golang.org/cl/11884043
This patch introduces specialized functions for initial
and final permutations, and precomputes the output of the
third permutation on the S-box elements.
benchmark old ns/op new ns/op delta
BenchmarkEncrypt 3581 1226 -65.76%
BenchmarkDecrypt 3590 1224 -65.91%
benchmark old MB/s new MB/s speedup
BenchmarkEncrypt 2.23 6.52 2.92x
BenchmarkDecrypt 2.23 6.53 2.93x
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/12072045
Update #5139.
Double wakeup on Note was reported several times,
but no reliable reproducer.
There also was a strange report about weird value of epoll fd.
Maybe it's corruption of global data...
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12182043
Sysmon thread parks if no goroutines are running (runtime.sched.npidle ==
runtime.gomaxprocs).
Currently it's unparked when a goroutine enters syscall, it was enough
to retake P's from blocking syscalls.
But it's not enough for reliable goroutine preemption. We need to ensure that
sysmon runs if any goroutines are running.
R=rsc
CC=golang-dev
https://golang.org/cl/12176043
Submitted with some unrelated changes that were not intended to go in.
««« original CL description
runtime: do not park sysmon thread if any goroutines are running
Sysmon thread parks if no goroutines are running (runtime.sched.npidle == runtime.gomaxprocs).
Currently it's unparked when a goroutine enters syscall, it was enough
to retake P's from blocking syscalls.
But it's not enough for reliable goroutine preemption. We need to ensure that
sysmon runs if any goroutines are running.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/12167043
»»»
R=rsc
CC=golang-dev
https://golang.org/cl/12171044
This is required to properly unwind reflect.methodValueCall/makeFuncStub.
Fixes#5954.
Stats for 'go install std':
61849 total INSTCALL
24655 currently have ArgSize metadata
27278 have ArgSize metadata with this change
godoc size before: 11351888, after: 11364288
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/12163043
Sysmon thread parks if no goroutines are running (runtime.sched.npidle == runtime.gomaxprocs).
Currently it's unparked when a goroutine enters syscall, it was enough
to retake P's from blocking syscalls.
But it's not enough for reliable goroutine preemption. We need to ensure that
sysmon runs if any goroutines are running.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/12167043
Adds layout cases with seconds for stdISO8601 and stdNumTZ with and without colons. Update time.Format to append seconds for those cases.
Fixes#4934.
R=golang-dev, r, bradfitz
CC=golang-dev
https://golang.org/cl/8132044
This means that printing a Node will produce output that can be used as valid input.
It won't be exactly the same - some spacing may be different - but it will mean the same.
Fixes#4593.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/12006047
When scanning input and "white space" is permitted, a carriage return
followed immediately by a newline (\r\n) is treated exactly the same
as a plain newline (\n). I hope this makes it work better on Windows.
We do it everywhere, not just on Windows, since why not?
Fixes#5391.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/12142043
When comparing strings, check these (in order):
- length mismatch => not equal
- string pointer equal => equal
- if length is short:
- memeq on body
- if length is long:
- compare first&last few bytes, if different => not equal
- save entry as a possible match
- after checking every entry, if there is only one possible
match, use memeq on that entry. Otherwise, fallback to hash.
benchmark old ns/op new ns/op delta
BenchmarkSameLengthMap 43 4 -89.77%
Fixes#5194.
Update #3885.
R=golang-dev, bradfitz, khr, rsc
CC=golang-dev
https://golang.org/cl/12128044
The prefix was not uniformly applied and is probably better left off anyway.
Fixes#4944.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/12140043
There is a chance that the SIGQUIT will make the test process
dump its stacks as part of exiting, which would be nice for
finding out what it is doing.
Right now the builders are occasionally timing out running
the runtime test. I hope this will give us some information
about the state of the runtime.
R=golang-dev, dave
CC=golang-dev
https://golang.org/cl/12041051
struct Hmap is the header for a map value.
CL 8377046 made flags a uint32 so that it could be updated atomically,
but that bumped the struct to 56 bytes, which allocates as 64 bytes (on amd64).
hash0 is initialized from runtime.fastrand1, which returns a uint32,
so the top 32 bits were always zero anyway. Declare it as a uint32
to reclaim 4 bytes and bring the Hmap size back down to a 48-byte allocation.
Fixes#5237.
R=golang-dev, khr, khr
CC=bradfitz, dvyukov, golang-dev
https://golang.org/cl/12034047
