- 01 Aug, 2013 26 commits
-
-
Brad Fitzpatrick authored
Fixes #3033 R=golang-dev, fvbommel, rsc CC=golang-dev https://golang.org/cl/12204043
-
Andrew Balholm authored
R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/12276043
-
Brad Fitzpatrick authored
I always forget which package has it. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/12214044
-
Russ Cox authored
Also move chatty recent additions to -v -v. For what it's worth: $ go build -o /dev/null -ldflags -v cmd/go ... 0.87 pclntab=1110836 bytes, funcdata total 69700 bytes ... $ This broke the ELF builds last time because I tried to dedup the funcdata in case the same funcdata was pointed at by multiple functions. That doesn't currently happen, so I've removed that test. If we start doing bitmap coalescing we'll need to figure out how to measure the size more carefully, but I think at that point the bitmaps will be an extra indirection away from the funcdata anyway, so the dedup I used before wouldn't help. R=ken2 CC=golang-dev https://golang.org/cl/12269043
-
Russ Cox authored
R=golang-dev, r CC=golang-dev https://golang.org/cl/12258043
-
Dmitriy Vyukov authored
This allows to at least determine goroutine "identity". Now it looks like: goroutine 12 [running]: goroutine running on other thread; stack unavailable created by testing.RunTests src/pkg/testing/testing.go:440 +0x88e R=golang-dev, r, rsc CC=golang-dev https://golang.org/cl/12248043
-
Dmitriy Vyukov authored
R=golang-dev, r CC=golang-dev https://golang.org/cl/12249043
-
Dmitriy Vyukov authored
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
-
Dmitriy Vyukov authored
It looks reasonable here and may be useful. R=golang-dev, r CC=golang-dev https://golang.org/cl/12252043
-
Dmitriy Vyukov authored
Currently fails with: fatal error: runtime: stack split during syscall goroutine 2 [stack split]: _vasop(0x3ac4a0, 0x505f8f00, 0x7a5a8, 0x7, 0x1ed3797f, ...) src/pkg/runtime/vlrt_arm.c:513 fp=0x505f8ecc runtime.semasleep(0xf8475800, 0xd) src/pkg/runtime/os_netbsd.c:97 +0x178 fp=0x505f8efc R=rsc CC=golang-dev https://golang.org/cl/12246043
-
Andrew Gerrand authored
Somehow missed these. Moved to go.tools/cmd/godoc/template. R=golang-dev CC=golang-dev https://golang.org/cl/12234043
-
Andrew Gerrand authored
R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/12075045
-
Brad Fitzpatrick authored
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
-
Brad Fitzpatrick authored
Fixes #5953 R=golang-dev, dsymonds CC=golang-dev https://golang.org/cl/12117043
-
Rémy Oudompheng authored
More functions needs to be marked as no stack split. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/11963044
-
Robert Griesemer authored
(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
-
Andrew Gerrand authored
These are moved to code.google.com/p/go.tools/cmd/godoc. R=golang-dev, r CC=golang-dev https://golang.org/cl/12220043
-
Russ Cox authored
Mark the 386 one too for consistency, although most of that code is no longer used. TBR=dvyukov CC=golang-dev https://golang.org/cl/12227043
-
Russ Cox authored
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
-
Andrew Gerrand authored
R=golang-dev, dave, dsymonds CC=golang-dev https://golang.org/cl/12225043
-
Chris Manghane authored
See also https://golang.org/cl/12180043/ R=adg CC=golang-dev https://golang.org/cl/12213043
-
Andrew Gerrand authored
R=golang-dev CC=golang-dev https://golang.org/cl/12222043
-
Andrew Gerrand authored
The godoc command now lives at code.google.com/p/go.tools/cmd/godoc. R=golang-dev, r CC=golang-dev https://golang.org/cl/12206044
-
Andrew Gerrand authored
Also suggest "go get" if godoc not found when running "go doc". R=golang-dev, r, rsc CC=golang-dev https://golang.org/cl/12214043
-
Robert Daniel Kortschak authored
Fixes #5998. R=golang-dev, khr CC=golang-dev https://golang.org/cl/12149043
-
Andrew Gerrand authored
R=golang-dev, dsymonds CC=golang-dev https://golang.org/cl/12208043
-
- 31 Jul, 2013 14 commits
-
-
Brad Fitzpatrick authored
Breaks all ELF builds. ««« original CL description cmd/ld: report pclntab, funcdata sizes in 6l -v output Also move chatty recent additions to -v -v. For what it's worth: $ go build -o /dev/null -ldflags -v cmd/godoc ... 0.73 pclntab=1259976 bytes, funcdata total 79788 bytes ... $ R=ken2 CC=cshapiro, golang-dev https://golang.org/cl/12193043 »»» R=rsc CC=golang-dev https://golang.org/cl/12202043
-
Rémy Oudompheng authored
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
-
Brad Fitzpatrick authored
R=golang-dev, r CC=golang-dev https://golang.org/cl/12174043
-
Rob Pike authored
1. They are FIFOs. 2. They are safe for concurrent access. Fixes #5911. R=golang-dev, dvyukov, adg CC=golang-dev https://golang.org/cl/11549043
-
Pieter Droogendijk authored
Fixes #4940. R=golang-dev, bradfitz, gri CC=golang-dev https://golang.org/cl/12021044
-
Robert Griesemer authored
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
-
Robert Griesemer authored
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émy Oudompheng authored
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
-
Russ Cox authored
Also move chatty recent additions to -v -v. For what it's worth: $ go build -o /dev/null -ldflags -v cmd/godoc ... 0.73 pclntab=1259976 bytes, funcdata total 79788 bytes ... $ R=ken2 CC=cshapiro, golang-dev https://golang.org/cl/12193043
-
Dmitriy Vyukov authored
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
-
Dmitriy Vyukov authored
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
-
Dmitriy Vyukov authored
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
-
Dmitriy Vyukov authored
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
-
Dmitriy Vyukov authored
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
-