Reduce duration of critical section,
make pcbuf local to function.
LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, rsc
https://golang.org/cl/102600043
Update #8525
Some temporary variables that were fully registerized nevertheless had stack space allocated for them because the Addrs were still marked as having associated nodes.
Distribution of stack space reserved for temporary variables while running make.bash (6g):
BEFORE
40.89% 7026 allocauto: 0 to 0
7.83% 1346 allocauto: 0 to 24
7.22% 1241 allocauto: 0 to 8
6.30% 1082 allocauto: 0 to 16
4.96% 853 allocauto: 0 to 56
4.59% 789 allocauto: 0 to 32
2.97% 510 allocauto: 0 to 40
2.32% 399 allocauto: 0 to 48
2.10% 360 allocauto: 0 to 64
1.91% 328 allocauto: 0 to 72
AFTER
48.49% 8332 allocauto: 0 to 0
9.52% 1635 allocauto: 0 to 16
5.28% 908 allocauto: 0 to 48
4.80% 824 allocauto: 0 to 32
4.73% 812 allocauto: 0 to 8
3.38% 581 allocauto: 0 to 24
2.35% 404 allocauto: 0 to 40
2.32% 399 allocauto: 0 to 64
1.65% 284 allocauto: 0 to 56
1.34% 230 allocauto: 0 to 72
LGTM=rsc
R=rsc
CC=dave, dvyukov, golang-codereviews, minux
https://golang.org/cl/126160043
cmd/6g has been doing this for a long time.
Arrays are still problematic on 5g because the addressing
for t[0] where local var t has type [3]uintptr takes the address of t.
That's issue 8125.
Fixes#8123.
LGTM=josharian
R=josharian, dave
CC=golang-codereviews
https://golang.org/cl/102890046
CL 130240043 did this but broke ARM, because
it made newErrorCString start allocating, so we rolled
it back in CL 133810043.
CL 133820043 removed that allocation.
Try again.
Fixes#8405.
LGTM=bradfitz, dave
R=golang-codereviews, bradfitz
CC=dave, golang-codereviews, r
https://golang.org/cl/133830043
Now 'go vet runtime' only shows:
malloc.go:200: possible misuse of unsafe.Pointer
malloc.go:214: possible misuse of unsafe.Pointer
malloc.go:250: possible misuse of unsafe.Pointer
stubs.go:167: possible misuse of unsafe.Pointer
Those are all unavoidable.
LGTM=josharian
R=golang-codereviews, dvyukov, josharian
CC=dave, golang-codereviews
https://golang.org/cl/135730043
It now serves as an example for go generate as well as for yacc.
NOTE: Depends on go generate, which is not yet checked in.
This is a proof of concept of the approach.
That is https://golang.org/cl/125580044.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/125620044
This is based on the crash dump provided by Alan
and on mental experiments:
sweep 0 74
fatal error: gc: unswept span
runtime stack:
runtime.throw(0x9df60d)
markroot(0xc208002000, 0x3)
runtime.parfordo(0xc208002000)
runtime.gchelper()
I think that when we moved all stacks into heap,
we introduced a bunch of bad data races. This was later
worsened by parallel stack shrinking.
Observation 1: exitsyscall can allocate a stack from heap at any time (including during STW).
Observation 2: parallel stack shrinking can (surprisingly) grow heap during marking.
Consider that we steadily grow stacks of a number of goroutines from 8K to 16K.
And during GC they all can be shrunk back to 8K. Shrinking will allocate lots of 8K
stacks, and we do not necessary have that many in heap at this moment. So shrinking
can grow heap as well.
Consequence: any access to mheap.allspans in GC (and otherwise) must take heap lock.
This is not true in several places.
Fix this by protecting accesses to mheap.allspans and introducing allspans cache for marking,
similar to what we use for sweeping.
LGTM=rsc
R=golang-codereviews, rsc
CC=adonovan, golang-codereviews, khr, rlh
https://golang.org/cl/126510043
The low-level implementation of divide on ARM assumes that
it can panic with an error created by newErrorCString without
allocating. If we make interface data words require pointer values,
the current definition would require an allocation when stored
in an interface. Changing the definition to use unsafe.Pointer
instead of uintptr avoids the allocation. This change is okay
because the field really is a pointer (to a C string in rodata).
Update #8405.
This should make CL 133830043 safe to try again.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=dave, golang-codereviews, r
https://golang.org/cl/133820043
This change broke divmod.go on all arm platforms.
««« original CL description
cmd/gc: change interface representation: only pointers in data word
Note that there are various cleanups that can be made if we keep
this change, but I do not want to start making changes that
depend on this one until the 1.4 cycle closes.
Fixes#8405.
LGTM=r
R=golang-codereviews, adg, r, bradfitz
CC=golang-codereviews, iant
https://golang.org/cl/130240043
»»»
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/133810043
This is a very dumb translation to keep the code as close to the original C as possible.
LGTM=rsc
R=khr, minux, rsc, josharian
CC=golang-codereviews
https://golang.org/cl/126490043
Note that there are various cleanups that can be made if we keep
this change, but I do not want to start making changes that
depend on this one until the 1.4 cycle closes.
Fixes#8405.
LGTM=r
R=golang-codereviews, adg, r, bradfitz
CC=golang-codereviews, iant
https://golang.org/cl/130240043
This makes newproc invisible to the GC. This is a pretty simple change since parts of newproc already depends on being run on the M stack.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews, khr
https://golang.org/cl/129520043
The current code is correct, but vet does not understand it:
asm_amd64.s:963: [amd64] invalid MOVL of ret+0(FP); int64 is 8-byte value
asm_amd64.s:964: [amd64] invalid offset ret+4(FP); expected ret+0(FP)
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/125200044
Fix issue by always appending newline after user input, before
the closing curly bracket. The adjust func is modified to remove
this new newline.
Add test case (it fails before CL, passes after).
Fixes#8411.
LGTM=gri
R=golang-codereviews, bradfitz, josharian, gri
CC=golang-codereviews
https://golang.org/cl/124700043
Fixes#8503.
Thanks to no.smile.face for the original report.
LGTM=bradfitz, r, ruiu
R=bradfitz, ruiu, r
CC=golang-codereviews
https://golang.org/cl/132730043
Add gofmt.go and gofmt_test.go as they are part of the test data set.
See CL 130440043.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews
https://golang.org/cl/132820044
1) Interpret a comment of the form
//gofmt <flags>
in test files to drive the respective
gofmt command. Eliminates the need to
enumerate all test files in the test
harness.
2) Added -update flag to make it easier
to update test cases.
LGTM=josharian
R=golang-codereviews, josharian
CC=golang-codereviews
https://golang.org/cl/130440043
Update #8527
Fixes, src/cmd/6l/../ld/pcln.c:93:18: runtime error: left shift of negative value -2
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/127440043
This files were added accidentally and are
not required for running the tests (they
are produced by failing tests for easier
debugging).
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/131030044
Fixes compilation of runtime on Solaris where the inner struct
was not called "_4_".
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/129460043
Australian timezones abbreviation for standard and daylight saving time were recently
changed from EST for both to AEST and AEDT in the icann tz database (see changelog
on www.iana.org/time-zones).
A test in the time package was written to check that the ParseInLocation function
understand that Feb EST and Aug EST are different time zones, even though they are
both called EST. This is no longer the case, and the Date function now returns
AEST or AEDT for australian tz on every Linux system with an up to date tz database
(and this makes the test fail).
Since I wasn't able to find another country that 1) uses daylight saving and 2) has
the same abbreviation for both on tzdata, I changed the test to make sure that
ParseInLocation does not get confused when it parses, in different locations, two
dates with the same abbreviation (this was suggested in the mailing list).
Fixes#8547.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/130920043
