| Age | Commit message (Collapse) | Author |
|
We need to change the interface value representation for
concurrent garbage collection, so that there is no ambiguity
about whether the data word holds a pointer or scalar.
This CL does NOT make any representation changes.
Instead, it removes representation assumptions from
various pieces of code throughout the tree.
The isdirectiface function in cmd/gc/subr.c is now
the only place that decides that policy.
The policy propagates out from there in the reflect
metadata, as a new flag in the internal kind value.
A follow-up CL will change the representation by
changing the isdirectiface function. If that CL causes
problems, it will be easy to roll back.
Update #8405.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/129090043
|
|
The change to pc-relative addressing will make this illegal.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/129890043
|
|
type T byte
func (T) String() string { return "X" }
fmt.Sprintf("%s", []T{97, 98, 99, 100}) == "abcd"
fmt.Sprintf("%x", []T{97, 98, 99, 100}) == "61626364"
fmt.Sprintf("%v", []T{97, 98, 99, 100}) == "[X X X X]"
This change makes the last case print correctly.
Before, it would have been "[97 98 99 100]".
Fixes #8360.
LGTM=r
R=r, dan.kortschak
CC=golang-codereviews
https://golang.org/cl/129330043
|
|
Improve performance of move-to-front by using cache-friendly
copies instead of doubly-linked list. Simplify so that the
underlying slice is the object. Remove the n=0 special case,
which was actually slower with the copy approach.
benchmark old ns/op new ns/op delta
BenchmarkDecodeDigits 26429714 23859699 -9.72%
BenchmarkDecodeTwain 76684510 67591946 -11.86%
benchmark old MB/s new MB/s speedup
BenchmarkDecodeDigits 1.63 1.81 1.11x
BenchmarkDecodeTwain 1.63 1.85 1.13x
Updates #6754.
LGTM=adg, agl, josharian
R=adg, agl, josharian
CC=golang-codereviews
https://golang.org/cl/131840043
|
|
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/130210043
|
|
LGTM=r, bradfitz
R=r, bradfitz
CC=golang-codereviews
https://golang.org/cl/127470043
|
|
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews, khr, rlh, rsc
https://golang.org/cl/125420043
|
|
Added in linux commit eb6452537b28
LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/130170043
|
|
Currently we do the following dance after sweeping a span:
1. lock mcentral
2. remove the span from a list
3. unlock mcentral
4. unmark span
5. lock mheap
6. insert the span into heap
7. unlock mheap
8. lock mcentral
9. observe empty list
10. unlock mcentral
11. lock mheap
12. grab the span
13. unlock mheap
14. mark span
15. lock mcentral
16. insert the span into empty list
17. unlock mcentral
This change short-circuits this sequence to nothing,
that is, we just cache and use the span after sweeping.
This gives us functionality similar (even better) to tcmalloc's transfer cache.
benchmark old ns/op new ns/op delta
BenchmarkMalloc8 22.2 19.5 -12.16%
BenchmarkMalloc16 31.0 26.6 -14.19%
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/119550043
|
|
Fixes #8530.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/124440043
|
|
Mallocgc must be atomic wrt GC, but for performance reasons
don't acquirem/releasem on fast path. The code does not have
split stack checks, so it can't be preempted by GC.
Functions like roundup/add are inlined. And onM/racemalloc are nosplit.
Also add debug code that checks these assumptions.
benchmark old ns/op new ns/op delta
BenchmarkMalloc8 20.5 17.2 -16.10%
BenchmarkMalloc16 29.5 27.0 -8.47%
BenchmarkMallocTypeInfo8 31.5 27.6 -12.38%
BenchmarkMallocTypeInfo16 34.7 30.9 -10.95%
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/123100043
|
|
Perf builders show 3-5% GC pause increase with GOMAXPROCS=1 when marking with atomic ops:
http://goperfd.appspot.com/perfdetail?commit=a8a6e765d6a87f7ccb71fd85a60eb5a821151f85&commit0=3b864e02b987171e05e2e9d0840b85b5b6476386&kind=builder&builder=linux-amd64&benchmark=http
LGTM=rlh
R=golang-codereviews, rlh
CC=dave, golang-codereviews, khr, rsc
https://golang.org/cl/128340043
|
|
In retrospect this should've been a variable instead of a type,
but oh well.
LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/129250044
|
|
Fixes #8512.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/130090043
|
|
bv.data is an array of uint32s but the code was using
offsets computed for an array of bytes.
Add a test for stack GC info.
Fixes #8531.
LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, khr, rsc
https://golang.org/cl/124450043
|
|
Fixes #8492
LGTM=alex.brainman
R=golang-codereviews, alex.brainman
CC=golang-codereviews
https://golang.org/cl/122200043
|
|
On the go.benchmarks/garbage benchmark with GOMAXPROCS=16:
old ns/op new ns/op delta
time 1392254 1353170 -2.81%
cputime 21995751 21373999 -2.83%
gc-pause-one 15044812 13050524 -13.26%
gc-pause-total 213636 185317 -13.26%
LGTM=rlh
R=golang-codereviews, rlh
CC=golang-codereviews, khr, rsc
https://golang.org/cl/123380043
|
|
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/123390043
|
|
In cgo, now that recursive calls to typeConv.Type() always work,
we can more robustly calculate the array sizes based on the size
of our element type.
Also, in debug/dwarf, the decision to call zeroType is made
based on a type's usage within a particular struct, but dwarf.Type
values are cached in typeCache, so the modification might affect
uses of the type in other structs. Current compilers don't appear
to share DWARF type entries for "[]foo" and "[0]foo", but they also
don't consistently share type entries in other cases. Arguably
modifying the types is an improvement in some cases, but varying
translated types according to compiler whims seems like a bad idea.
Lastly, also in debug/dwarf, zeroType only needs to rewrite the
top-level dimension, and only if the rest of the array size is
non-zero.
Fixes #8428.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/127980043
|
|
Restore https://golang.org/cl/41040043 after GC rewrite.
Original description:
On the plus side, we don't need to change the bits on malloc and free.
On the downside, we need to mark objects in the free lists during GC.
But the free lists are small at GC time, so it should be a net win.
benchmark old ns/op new ns/op delta
BenchmarkMalloc8 21.9 20.4 -6.85%
BenchmarkMalloc16 31.1 29.6 -4.82%
LGTM=khr
R=khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/122280043
|
|
The file is used by assembly code to define symbols like NOSPLIT.
Having it hidden inside the cmd directory makes it hard to access
outside the standard repository.
Solution: As with a couple of other files used by cgo, copy the
file into the pkg directory and add a -I argument to the assembler
to access it. Thus one can write just
#include "textflag.h"
in .s files.
The names in runtime are not updated because in the boot sequence the
file has not been copied yet when runtime is built. All other .s files
in the repository are updated.
Changes to doc/asm.html, src/cmd/dist/build.c, and src/cmd/go/build.go
are hand-made. The rest are just the renaming done by a global
substitution. (Yay sam).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/128050043
|
|
This allows changing the addressing mode for constant
global addresses to use pc-relative addressing.
LGTM=rminnich, iant
R=golang-codereviews, rminnich, iant
CC=golang-codereviews
https://golang.org/cl/129830043
|
|
Add a clause to the doc comment for the package and a
paragraph in the compatibility document explaining the
situation.
LGTM=bradfitz, adg, rsc
R=golang-codereviews, adg, bradfitz, minux, rsc
CC=golang-codereviews
https://golang.org/cl/129820043
|
|
See golang.org/s/go14customimport for design.
Added case to deps_test to allow go/build to import regexp.
Not a new dependency, because go/build already imports go/doc
which imports regexp.
Fixes #7453.
LGTM=r
R=r, josharian
CC=golang-codereviews
https://golang.org/cl/124940043
|
|
Adds internal/syscall package.
Fixes #8520
LGTM=r, agl
R=agl, rsc, r
CC=golang-codereviews, iant
https://golang.org/cl/123260044
|
|
Turns out to be unused as well.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews, khr
https://golang.org/cl/127170044
|
|
It's unclear why we do this broken double-checked locking.
The mutex is not held for the whole duration of CPU profiling.
Fixes #8365.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/116290043
|
|
Tested against GnuTLS and Python.
LGTM=agl
R=golang-codereviews, agl, ashankar
CC=agl, golang-codereviews
https://golang.org/cl/117100043
|
|
Our other CloseFlushers (archive/tar, compress/flate) do mention this.
The original change was accidentally submitted to the release branch:
https://golang.org/cl/117430043/
TBR=rsc
R=r, rsc
CC=golang-codereviews
https://golang.org/cl/124130043
|
|
Replaces CL 123980043 which I created on the dev.power64 branch.
LGTM=rsc
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/123120043
|
|
When formatting time zone offsets with seconds using the stdISO8601Colon
and stdNumColon layouts, the colon was missing between the hour and minute
parts.
Fixes #8497.
LGTM=r
R=golang-codereviews, iant, gobot, r
CC=golang-codereviews
https://golang.org/cl/126840043
|
|
There was a number of improvements related to GC parallelization:
1. Parallel roots/stacks scanning.
2. Parallel stack shrinking.
3. Per-thread workbuf caches.
4. Workset reduction.
Currently 32 threads work well.
go.benchmarks:garbage benchmark on 2 x Intel Xeon E5-2690 (16 HT cores)
1 thread/1 processor:
time=16405255
cputime=16386223
gc-pause-one=546793975
gc-pause-total=3280763
2 threads/1 processor:
time=9043497
cputime=18075822
gc-pause-one=331116489
gc-pause-total=2152257
4 threads/1 processor:
time=4882030
cputime=19421337
gc-pause-one=174543105
gc-pause-total=1134530
8 threads/1 processor:
time=4134757
cputime=20097075
gc-pause-one=158680588
gc-pause-total=1015555
16 threads/1 processor + HT:
time=2006706
cputime=31960509
gc-pause-one=75425744
gc-pause-total=460097
16 threads/2 processors:
time=1513373
cputime=23805571
gc-pause-one=56630946
gc-pause-total=345448
32 threads/2 processors + HT:
time=1199312
cputime=37592764
gc-pause-one=48945064
gc-pause-total=278986
LGTM=rlh
R=golang-codereviews, tracey.brendan, rlh
CC=golang-codereviews, khr, rsc
https://golang.org/cl/123920043
|
|
Update #8092
LGTM=dvyukov
R=golang-codereviews, minux, dvyukov
CC=golang-codereviews
https://golang.org/cl/122250043
|
|
Stack shrinking happens during mark phase,
and it assumes that it owns stackcache in mcache.
Stack cache flushing also happens during mark phase,
and it accesses stackcache's w/o any synchronization.
This leads to stackcache corruption:
http://goperfd.appspot.com/log/309af5571dfd7e1817259b9c9cf9bcf9b2c27610
LGTM=khr
R=khr
CC=golang-codereviews, rsc
https://golang.org/cl/126870043
|
|
On OS X 10.10 Yosemite, if you have a directory that can be returned
in a single getdirentries64 call (for example, a directory with one file),
and you read from the directory at EOF twice, you get EOF both times:
fd = open("dir")
getdirentries64(fd) returns data
getdirentries64(fd) returns 0 (EOF)
getdirentries64(fd) returns 0 (EOF)
But if you remove the file in the middle between the two calls, the
second call returns an error instead.
fd = open("dir")
getdirentries64(fd) returns data
getdirentries64(fd) returns 0 (EOF)
remove("dir/file")
getdirentries64(fd) returns ENOENT/EINVAL
Whether you get ENOENT or EINVAL depends on exactly what was
in the directory. It is deterministic, just data-dependent.
This only happens in small directories. A directory containing more data
than fits in a 4k getdirentries64 call will return EOF correctly.
(It's not clear if the criteria is that the directory be split across multiple
getdirentries64 calls or that it be split across multiple file system blocks.)
We could change package os to avoid the second read at EOF,
and maybe we should, but that's a bit involved.
For now, treat the EINVAL/ENOENT as EOF.
With this CL, all.bash passes on my MacBook Air running
OS X 10.10 (14A299l) and Xcode 6 beta 5 (6A279r).
I tried filing an issue with Apple using "Feedback Assistant", but it was
unable to send the report and lost it.
C program reproducing the issue, also at http://swtch.com/~rsc/readdirbug.c:
#include <stdio.h>
#include <dirent.h>
#include <unistd.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
static void test(int);
int
main(void)
{
int fd, n;
DIR *dir;
struct dirent *dp;
struct stat st;
char buf[10000];
long basep;
int saw;
if(stat("/tmp/readdirbug", &st) >= 0) {
fprintf(stderr, "please rm -r /tmp/readdirbug and run again\n");
exit(1);
}
fprintf(stderr, "mkdir /tmp/readdirbug\n");
if(mkdir("/tmp/readdirbug", 0777) < 0) {
perror("mkdir /tmp/readdirbug");
exit(1);
}
fprintf(stderr, "create /tmp/readdirbug/file1\n");
if((fd = creat("/tmp/readdirbug/file1", 0666)) < 0) {
perror("create /tmp/readdirbug/file1");
exit(1);
}
close(fd);
test(0);
test(1);
fprintf(stderr, "ok - everything worked\n");
}
static void
test(int doremove)
{
DIR *dir;
struct dirent *dp;
int numeof;
fprintf(stderr, "\n");
fprintf(stderr, "opendir /tmp/readdirbug\n");
dir = opendir("/tmp/readdirbug");
if(dir == 0) {
perror("open /tmp/readdirbug");
exit(1);
}
numeof = 0;
for(;;) {
errno = 0;
dp = readdir(dir);
if(dp != 0) {
fprintf(stderr, "readdir: found %s\n", dp->d_name);
continue;
}
if(errno != 0) {
perror("readdir");
exit(1);
}
fprintf(stderr, "readdir: EOF\n");
if(++numeof == 3)
break;
if(doremove) {
fprintf(stderr, "rm /tmp/readdirbug/file1\n");
if(remove("/tmp/readdirbug/file1") < 0) {
perror("remove");
exit(1);
}
}
}
fprintf(stderr, "closedir\n");
closedir(dir);
}
Fixes #8423.
LGTM=bradfitz, r
R=golang-codereviews, bradfitz, dsymonds, dave, r
CC=golang-codereviews, iant
https://golang.org/cl/119530044
|
|
All goroutines decode into the same value.
LGTM=r
R=r, abursavich
CC=golang-codereviews
https://golang.org/cl/123930043
|
|
as per rsc request
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/123970043
|
|
Current version of Getwd calls Stat that
calls Getwd therefore infinite recursion.
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/119600043
|
|
Fixes #8342.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/122180043
|
|
Fixes #8314.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/125820043
|
|
LGTM=rsc
R=rsc, khr
CC=golang-codereviews
https://golang.org/cl/121330043
|
|
LGTM=dvyukov
R=golang-codereviews, dave, bradfitz, dvyukov, khr
CC=golang-codereviews
https://golang.org/cl/98510044
|
|
C compiler does not support unnamed fields.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/124870043
|
|
The ast and printer don't care, and go/types can provide
a better error message.
This change requires an update to the tests for go/types
(go.tools repo). CL forthcoming.
Fixes #8493.
LGTM=adonovan
R=rsc, adonovan
CC=golang-codereviews
https://golang.org/cl/123010044
|
|
LGTM=dvyukov
R=dvyukov, khr
CC=golang-codereviews
https://golang.org/cl/121030043
|
|
There are lots of internal synchronization in gob,
so it makes sense to have parallel benchmarks.
Also add a benchmark with slices and interfaces.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/115960043
|
|
This lets us have non-main packages like cmd/internal or cmd/nm/internal/whatever.
The src/pkg migration (see golang.org/s/go14mainrepo) will allow this
as a natural side effect. The explicit change here just allows use of the
effect a little sooner.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/117630043
|
|
Eliminating use of this extension makes it easier to port the Go runtime
to other compilers. This CL also disables the extension in cc to prevent
accidental use.
LGTM=rsc, khr
R=rsc, aram, khr, dvyukov
CC=axwalk, golang-codereviews
https://golang.org/cl/106790044
|
|
This makes os.Getwd mimic C getwd on OS X,
and possibly other systems. The change on OS X
was a regression from 1.2 to 1.3.
Fixes #8400.
LGTM=bradfitz
R=iant, bradfitz
CC=golang-codereviews
https://golang.org/cl/118970043
|
|
benchmark old ns/op new ns/op delta
BenchmarkMalloc8 28.7 22.4 -21.95%
BenchmarkMalloc16 44.8 33.8 -24.55%
BenchmarkMallocTypeInfo8 49.0 32.9 -32.86%
BenchmarkMallocTypeInfo16 46.7 35.8 -23.34%
BenchmarkMallocLargeStruct 907 901 -0.66%
BenchmarkGobDecode 13235542 12036851 -9.06%
BenchmarkGobEncode 10639699 9539155 -10.34%
BenchmarkJSONEncode 25193036 21898922 -13.08%
BenchmarkJSONDecode 96104044 89464904 -6.91%
Fixes #8452.
LGTM=khr
R=golang-codereviews, bradfitz, rsc, dave, khr
CC=golang-codereviews
https://golang.org/cl/122090043
|