Make sure dequeueing from a channel queue does not exhibit quadratic time behavior.
Change-Id: Ifb7c709b026f74c7e783610d4914dd92909a441b
Reviewed-on: https://go-review.googlesource.com/1212
Reviewed-by: Russ Cox <rsc@golang.org>
Usage:
fibo <n> compute fibonacci(n), n must be >= 0
fibo -bench benchmark fibonacci computation (takes about 1 min)
Additional flags:
-half add values using two half-digit additions
-opt optimize memory allocation through reuse
-short only print the first 10 digits of very large fibonacci numbers
This change was reviewed in detail as https://codereview.appspot.com/168480043 .
Change-Id: I7c86d49c5508532ea6206d00f424cf2117d2fe41
Reviewed-on: https://go-review.googlesource.com/1211
Reviewed-by: Russ Cox <rsc@golang.org>
Avoids a potential O(n^2) performance problem when dequeueing
from very popular channels.
benchmark old ns/op new ns/op delta
BenchmarkChanPopular 2563782 627201 -75.54%
Change-Id: I231aaeafea0ecd93d27b268a0b2128530df3ddd6
Reviewed-on: https://go-review.googlesource.com/1200
Reviewed-by: Russ Cox <rsc@golang.org>
If the symbol table isn't sorted, we print it and abort. However, we
were missing the line break after each symbol, resulting in one
gigantic line instead of a nicely formatted table.
Change-Id: Ie5c6f3c256d0e648277cb3db4496512a79d266dd
Reviewed-on: https://go-review.googlesource.com/1182
Reviewed-by: Russ Cox <rsc@golang.org>
It is unused. It was introduced in the CL that added InputOffset.
I suspect it was an editing mistake.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/182580043
When we start work on Gerrit, ppc64 and garbage collection
work will continue in the master branch, not the dev branches.
(We may still use dev branches for other things later, but
these are ready to be merged, and doing it now, before moving
to Git means we don't have to have dev branches working
in the Gerrit workflow on day one.)
TBR=rlh
CC=golang-codereviews
https://golang.org/cl/183140043
640 bytes ought to be enough for anybody.
We'll bring this back down before Go 1.5. That's issue 9214.
TBR=rlh
CC=golang-codereviews
https://golang.org/cl/188730043
This is going to hurt a bit but we'll make it better later.
Now the race detector can be run again.
I added the write barrier optimizations from
CL 183020043 to try to make it hurt a little less.
TBR=rlh
CC=golang-codereviews
https://golang.org/cl/185070043
This is the last system-dependent file written by cmd/dist.
They are all now written by go generate.
cmd/dist is not needed to start building package runtime
for a different system anymore.
Now all the generated files can be assumed generated, so
delete the clumsy hacks in cmd/api.
Re-enable api check in run.bash.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/185040044
With this change, default now contains Go 1.5 work.
Any future bug fixes for Go 1.4 in the compilers or
the runtime will have to be made directly to the
release branch.
When liblink sees something like
JMP x
...
x: JMP y
it rewrites the first jump to jump directly to y. This is
fine if y is a resolved label. However, it *also* does this
if y is a function symbol, but fails to carry over the
relocation that would later patch in that symbol's value. As
a result, the original jump becomes either a self-jump (if
relative) or a jump to PC 0 (if absolute).
Fix this by disabling this optimization if the jump being
patched in is a jump to a symbol.
LGTM=minux
R=rsc, minux
CC=golang-codereviews
https://golang.org/cl/185890044
Frankly, I don't understand how the current code could possibly work except
when every android program is using cgo. Discovered this while working on
the iOS port.
LGTM=crawshaw, rsc
R=rsc, crawshaw
CC=golang-codereviews
https://golang.org/cl/177470043
The new semantics of split require the newline be present.
The test was stale.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/182480043
Scanner can't handle stupid long lines and there are
reports of stupid long lines in production.
Note the issue isn't long "//go:generate" lines, but
any long line in any Go source file.
To be fair, if you're going to have a stupid long line
it's not a bad bet you'll want to run it through go
generate, because it's some embeddable asset that
has been machine generated. (One could ask why
that generation process didn't add a newline or two,
but we should cope anyway.)
Rewrite the file scanner in "go generate" so it can
handle arbitrarily long lines, and only stores in memory
those lines that start "//go:generate".
Also: Adjust the documentation to make clear that it
does not parse the file.
Fixes#9143.
Fixes#9196.
LGTM=rsc, dominik.honnef
R=rsc, cespare, minux, dominik.honnef
CC=golang-codereviews
https://golang.org/cl/182970043
While we're at there, also add a message to prompt the user to install
Graphviz if "dot" command is not found.
Fixes#9178.
LGTM=adg, alex.brainman, cookieo9, rsc
R=rsc, adg, bradfitz, alex.brainman, cookieo9, smyrman
CC=golang-codereviews
https://golang.org/cl/180380043
Move change from CL 170770043 to correct file and regenerate docs
for changes from CL 164120043.
LGTM=adg
R=golang-codereviews, adg, bradfitz
CC=golang-codereviews
https://golang.org/cl/183000043
During garbage collection, after scanning a stack, we think about
shrinking it to reclaim some memory. The shrinking code (called
while the world is stopped) checked that the status was Gwaiting
or Grunnable and then changed the state to Gcopystack, to essentially
lock the stack so that no other GC thread is scanning it.
The same locking happens for stack growth (and is more necessary there).
oldstatus = runtime·readgstatus(gp);
oldstatus &= ~Gscan;
if(oldstatus == Gwaiting || oldstatus == Grunnable)
runtime·casgstatus(gp, oldstatus, Gcopystack); // oldstatus is Gwaiting or Grunnable
else
runtime·throw("copystack: bad status, not Gwaiting or Grunnable");
Unfortunately, "stop the world" doesn't stop everything. It stops all
normal goroutine execution, but the network polling thread is still
blocked in epoll and may wake up. If it does, and it chooses a goroutine
to mark runnable, and that goroutine is the one whose stack is shrinking,
then it can happen that between readgstatus and casgstatus, the status
changes from Gwaiting to Grunnable.
casgstatus assumes that if the status is not what is expected, it is a
transient change (like from Gwaiting to Gscanwaiting and back, or like
from Gwaiting to Gcopystack and back), and it loops until the status
has been restored to the expected value. In this case, the status has
changed semi-permanently from Gwaiting to Grunnable - it won't
change again until the GC is done and the world can continue, but the
GC is waiting for the status to change back. This wedges the program.
To fix, call a special variant of casgstatus that accepts either Gwaiting
or Grunnable as valid statuses.
Without the fix bug with the extra check+throw in casgstatus, the
program below dies in a few seconds (2-10) with GOMAXPROCS=8
on a 2012 Retina MacBook Pro. With the fix, it runs for minutes
and minutes.
package main
import (
"io"
"log"
"net"
"runtime"
)
func main() {
const N = 100
for i := 0; i < N; i++ {
l, err := net.Listen("tcp", "127.0.0.1:0")
if err != nil {
log.Fatal(err)
}
ch := make(chan net.Conn, 1)
go func() {
var err error
c1, err := net.Dial("tcp", l.Addr().String())
if err != nil {
log.Fatal(err)
}
ch <- c1
}()
c2, err := l.Accept()
if err != nil {
log.Fatal(err)
}
c1 := <-ch
l.Close()
go netguy(c1, c2)
go netguy(c2, c1)
c1.Write(make([]byte, 100))
}
for {
runtime.GC()
}
}
func netguy(r, w net.Conn) {
buf := make([]byte, 100)
for {
bigstack(1000)
_, err := io.ReadFull(r, buf)
if err != nil {
log.Fatal(err)
}
w.Write(buf)
}
}
var g int
func bigstack(n int) {
var buf [100]byte
if n > 0 {
bigstack(n - 1)
}
g = int(buf[0]) + int(buf[99])
}
Fixes#9186.
LGTM=rlh
R=austin, rlh
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/179680043
These accomplished the same thing, but R_CALLPOWER expected
the whole instruction to be in the addend (and completely
overwrote what was in the text section), while R_PPC64_REL24
overwrites only bits 6 through 24 of whatever was in the text
section. Make R_CALLPOWER work like R_PPC64_REL24 to ease the
implementation of dynamic linking.
LGTM=rsc
R=rsc
CC=golang-codereviews, minux
https://golang.org/cl/177430043
warning: src/cmd/5g/reg.c:461 format mismatch d VLONG, arg 5
warning: src/cmd/6g/reg.c:396 format mismatch d VLONG, arg 5
warning: src/cmd/9g/reg.c:440 format mismatch d VLONG, arg 5
LGTM=minux
R=rsc, minux
CC=golang-codereviews
https://golang.org/cl/179300043
This was based on the 9c peephole optimizer, modified to work
with code generated by gc and use the proginfo infrastructure
in gc.
LGTM=rsc
R=rsc, bradfitz, minux
CC=golang-codereviews
https://golang.org/cl/179190043
This adds some utilities for converting between the CC, V, and
VCC variants of operations and uses these to derive the
ProgInfo entries for these variants (which are identical to
the ProgInfo for the base operations).
The 9g peephole optimizer will also use these conversion
utilities.
LGTM=minux, rsc
R=rsc, dave, minux
CC=golang-codereviews
https://golang.org/cl/180110044
