Fixes#2337.
Unfortunate sequence of events is:
1. maxcpu=2, mcpu=1, grunning=1
2. starttheworld creates an extra M:
maxcpu=2, mcpu=2, grunning=1
4. the goroutine calls runtime.GOMAXPROCS(1)
maxcpu=1, mcpu=2, grunning=1
5. since it sees mcpu>maxcpu, it calls gosched()
6. schedule() deschedules the goroutine:
maxcpu=1, mcpu=1, grunning=0
7. schedule() call getnextandunlock() which
fails to pick up the goroutine again,
because canaddcpu() fails, because mcpu==maxcpu
8. then it sees that grunning==0,
reports deadlock and terminates
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5191044
My previous CL:
changeset: 9645:ce2e5f44b310
user: Russ Cox <rsc@golang.org>
date: Tue Sep 06 10:24:21 2011 -0400
summary: gc: unify stack frame layout
introduced a bug wherein no variables were
being registerized, making Go programs 2-3x
slower than they had been before.
This CL fixes that bug (along with some others
it was hiding) and adds a test that optimization
makes at least one test case faster.
R=ken2
CC=golang-dev
https://golang.org/cl/5174045
Running test/garbage/parser.out.
On a 4-core Lenovo X201s (Linux):
31.12u 0.60s 31.74r 1 cpu, no atomics
32.27u 0.58s 32.86r 1 cpu, atomic instructions
33.04u 0.83s 27.47r 2 cpu
On a 16-core Xeon (Linux):
33.08u 0.65s 33.80r 1 cpu, no atomics
34.87u 1.12s 29.60r 2 cpu
36.00u 1.87s 28.43r 3 cpu
36.46u 2.34s 27.10r 4 cpu
38.28u 3.85s 26.92r 5 cpu
37.72u 5.25s 26.73r 6 cpu
39.63u 7.11s 26.95r 7 cpu
39.67u 8.10s 26.68r 8 cpu
On a 2-core MacBook Pro Core 2 Duo 2.26 (circa 2009, MacBookPro5,5):
39.43u 1.45s 41.27r 1 cpu, no atomics
43.98u 2.95s 38.69r 2 cpu
On a 2-core Mac Mini Core 2 Duo 1.83 (circa 2008; Macmini2,1):
48.81u 2.12s 51.76r 1 cpu, no atomics
57.15u 4.72s 51.54r 2 cpu
The handoff algorithm is really only good for two cores.
Beyond that we will need to so something more sophisticated,
like have each core hand off to the next one, around a circle.
Even so, the code is a good checkpoint; for now we'll limit the
number of gc procs to at most 2.
R=dvyukov
CC=golang-dev
https://golang.org/cl/4641082
The 512 MB array causes load delays on some systems.
Now that we have recover, we can do all the tests in
one binary, so that the delay is incurred just once.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5142044
Alex Brainman reports that this is the only test
that keeps us from running test/run.
R=alex.brainman, lucio.dere, bradfitz, hectorchu
CC=golang-dev
https://golang.org/cl/4777043
bug340.go:14:7: error: expected type
bug340.go:15:4: error: reference to undefined field or method ‘x’
bug350.go:12:1: error: redefinition of ‘m’
bug350.go:11:1: note: previous definition of ‘m’ was here
bug350.go:15:1: error: redefinition of ‘p’
bug350.go:14:1: note: previous definition of ‘p’ was here
bug351.go:12:6: error: non-name on left side of ‘:=’
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5127041
bug363.go:13:12: error: invalid context-determined non-integer type for shift operand
bug363.go:16:12: error: invalid context-determined non-integer type for shift operand
pointer.go:34:6: error: incompatible type in initialization (pointer to interface type has no methods)
pointer.go:36:6: error: incompatible type in initialization
method2.go:15:1: error: invalid pointer or interface receiver type
method2.go:16:1: error: invalid pointer or interface receiver type
method2.go:21:1: error: invalid pointer or interface receiver type
method2.go:22:1: error: invalid pointer or interface receiver type
method2.go:28:15: error: type ‘*Val’ has no method ‘val’
method2.go:33:11: error: reference to undefined field or method ‘val’
shift1.go:19:16: error: invalid context-determined non-integer type for shift operand
shift1.go:24:19: error: invalid context-determined non-integer type for shift operand
shift1.go:25:17: error: invalid context-determined non-integer type for shift operand
shift1.go:18:18: error: shift of non-integer operand
shift1.go:26:13: error: floating point constant truncated to integer
shift1.go:33:15: error: integer constant overflow
shift1.go:34:15: error: integer constant overflow
shift1.go:35:17: error: integer constant overflow
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5081051
Added a return to bug357.go to avoid an error which gccgo
reports but 6g does not.
bug353.go:16:14: error: reference to undefined identifer ‘io.ReadWriterCloser’
bug357.go:18:2: error: value computed is not used
bug358.go:14:11: error: imported and not used: ioutil
bug358.go:19:9: error: invalid use of type
bug359.go:25:14: error: redefinition of ‘a’
bug359.go:25:6: note: previous definition of ‘a’ was here
bug359.go:19:6: error: incompatible type in initialization (implicit assignment of ‘list.List’ hidden field ‘front’)
bug362.go:13:6: error: iota is only defined in const declarations
bug362.go:14:6: error: iota is only defined in const declarations
bug362.go:15:6: error: iota is only defined in const declarations
bug363.go:13:12: error: shift of non-integer operand
bug363.go:16:12: error: shift of non-integer operand
bug365.go:15:8: error: expected package
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5078046
bug349.go:12:14: error: expected ‘;’ or ‘}’ or newline
bug349.go:12:2: error: not enough arguments to return
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5081047
The algtype-based test broke when algtype
got a bit more fine-grained, so replace with
an explicit check for the invalid key types.
R=ken2
CC=golang-dev
https://golang.org/cl/5071041
The spec says that all methods are inherited from an anonymous
field. There is no exception for non-exported methods.
This is related to issue 1536.
R=rsc
CC=golang-dev
https://golang.org/cl/5012043
Was keeping a pointer to the labeled statement in n->right,
which meant that generic traversals of the tree visited it twice.
That combined with aggressive flattening of the block
structure when possible during parsing meant that
the kinds of label: code label: code label: code sequences
generated by yacc were giving the recursion 2ⁿ paths
through the program.
Fixes#2212.
R=lvd
CC=golang-dev
https://golang.org/cl/4960050
Does as much as possible in data layout instead
of during the init function.
Handles var x = y; var y = z as a special case too,
because it is so prevalent in package unicode
(var Greek = _Greek; var _Greek = []...).
Introduces InitPlan description of initialized data
so that it can be traversed multiple times (for example,
in the copy handler).
Cuts package unicode's init function size by 8x.
All that remains there is map initialization, which
is on the chopping block too.
Fixes sinit.go test case.
Aggregate DATA instructions at end of object file.
Checkpoint. More to come.
R=ken2
CC=golang-dev
https://golang.org/cl/4969051
Escape analysis was incorrectly assuming that
functions without bodies don't leak their
parameters. This meant that sync/atomic's
TestAddInt64 was allocating x on its stack,
and then x was not properly aligned for use
with the atomic 64-bit instructions. Obviously
we should figure out the alignment story on 5g
too, but this fix is correct and should restore the
build to 'ok'.
TBR=lvd
CC=golang-dev
https://golang.org/cl/4964047
-s now means *disable* escape analysis.
Fix escape leaks for struct/slice/map literals.
Add ... tracking.
Rewrite new(T) and slice literal into stack allocation when safe.
Add annotations to reflect.
Reflect is too chummy with the compiler,
so changes like these affect it more than they should.
R=lvd, dave, gustavo
CC=golang-dev
https://golang.org/cl/4954043
For now it's switch-on-and-offable with -s, and the effects can be inspected
with -m. Defaults are the old codepaths.
R=rsc
CC=golang-dev
https://golang.org/cl/4634073
Make the stack traces more readable for new
Go programmers while preserving their utility for old hands.
- Change status number [4] to string.
- Elide frames in runtime package (internal details).
- Swap file:line and arguments.
- Drop 'created by' for main goroutine.
- Show goroutines in order of allocation:
implies main goroutine first if nothing else.
There is no option to get the extra frames back.
Uncomment 'return 1' at the bottom of symtab.c.
$ 6.out
throw: all goroutines are asleep - deadlock!
goroutine 1 [chan send]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:22 +0x8a
goroutine 2 [select (no cases)]:
main.sel()
/Users/rsc/g/go/src/pkg/runtime/x.go:11 +0x18
created by main.main
/Users/rsc/g/go/src/pkg/runtime/x.go:19 +0x23
goroutine 3 [chan receive]:
main.recv(0xf8400010a0, 0x0)
/Users/rsc/g/go/src/pkg/runtime/x.go:15 +0x2e
created by main.main
/Users/rsc/g/go/src/pkg/runtime/x.go:20 +0x50
goroutine 4 [chan receive (nil chan)]:
main.recv(0x0, 0x0)
/Users/rsc/g/go/src/pkg/runtime/x.go:15 +0x2e
created by main.main
/Users/rsc/g/go/src/pkg/runtime/x.go:21 +0x66
$
$ 6.out index
panic: runtime error: index out of range
goroutine 1 [running]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:25 +0xb9
$
$ 6.out nil
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x22ca]
goroutine 1 [running]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:28 +0x211
$
$ 6.out panic
panic: panic
goroutine 1 [running]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:30 +0x101
$
R=golang-dev, qyzhai, n13m3y3r, r
CC=golang-dev
https://golang.org/cl/4907048
I converted this program yesterday and the output is the
same as it used to be, ignoring space, but the result is
not the best expression of the algorithm. The old {.section
Maybe} pieces are now {{with .Maybe}}, as a direct translation,
but I they should be {{if .Maybe}} as the output is just a
bool and there is no cascading.
I have verified that the output of the program is unaffected.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/4889053
It's already in old/template; make that build.
Update a couple of references to point to the old template.
They can be updated later.
Update goplay to use exp/template.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/4902046
// ERROR "pattern1" "pattern2"
means that there has to be one or more
lines matching pattern1 and then excluding
those, there have to be one or more lines
matching pattern2. So if you expect two
different error messages from a particular
line, writing two separate patterns checks
that both errors are produced.
Also, errchk now flags lines that produce
more errors than expected. Before, as long as
at least one error matched the pattern, all the
others were ignored.
Revise tests to expect or silence these
additional errors.
R=lvd, r, iant
CC=golang-dev
https://golang.org/cl/4869044
Some tests are significantly faster (50%), a few are slower (up to 30%).
Fannkuch is confusing: parallel code is a little slower for gc, non-parallel and all gccgo runs are faster.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/4830058
