GitLab

For gccgo runtime and Darwin where -fno-common is the default.

R=iant, dave
CC=golang-dev
https://golang.org/cl/7094061

benchmark                      old ns/op    new ns/op    delta
BenchmarkStackGrowth                 665          548  -17.59%
BenchmarkStackGrowth-2               333          274  -17.72%
BenchmarkStackGrowth-4               224          168  -25.00%
BenchmarkStackGrowth-8               124           91  -26.21%
BenchmarkStackGrowth-16               82           70  -14.55%
BenchmarkStackGrowth-32               73           59  -19.49%

R=nigeltao, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/7026044

Introduce global stack segment cache and limit per-thread cache size.
This greatly reduces StackSys memory on workloads that create lots of threads.

benchmark                      old ns/op    new ns/op    delta
BenchmarkStackGrowth                 665          656   -1.35%
BenchmarkStackGrowth-2               333          328   -1.50%
BenchmarkStackGrowth-4               224          172  -23.21%
BenchmarkStackGrowth-8               124           91  -26.13%
BenchmarkStackGrowth-16               82           47  -41.94%
BenchmarkStackGrowth-32               73           40  -44.79%

BenchmarkStackGrowthDeep           97231        94391   -2.92%
BenchmarkStackGrowthDeep-2         47230        58562  +23.99%
BenchmarkStackGrowthDeep-4         24993        49356  +97.48%
BenchmarkStackGrowthDeep-8         15105        30072  +99.09%
BenchmarkStackGrowthDeep-16        10005        15623  +56.15%
BenchmarkStackGrowthDeep-32        12517        13069   +4.41%

TestStackMem#1,MB                  310          12       -96.13%
TestStackMem#2,MB                  296          14       -95.27%
TestStackMem#3,MB                  479          14       -97.08%

TestStackMem#1,sec                 3.22         2.26     -29.81%
TestStackMem#2,sec                 2.43         2.15     -11.52%
TestStackMem#3,sec                 2.50         2.38      -4.80%

R=sougou, no.smile.face, rsc
CC=golang-dev, msolomon
https://golang.org/cl/7029044

Fixes #3996.

R=ken2
CC=golang-dev
https://golang.org/cl/7001052

runtime: use "mp" and "gp" instead of "m" and "g" for local variable name to avoid confusion with the global "m" and "g".

R=golang-dev, minux.ma, rsc
CC=bradfitz, golang-dev
https://golang.org/cl/6939064

Incorporates code from CL 6828055.

Fixes #2142.

R=golang-dev, iant, devon.odell
CC=golang-dev
https://golang.org/cl/6826088

Currently race detector runtime maps shadow memory eagerly at process startup.
It works poorly on Windows, because Windows requires reservation in swap file
(especially problematic if several Go program runs at the same, each consuming GBs
of memory).
With this change race detector maps shadow memory lazily, so Go runtime must notify
about all new heap memory.
It will help with Windows port, but also eliminates scary 16TB virtual mememory
consumption in top output (which sometimes confuses some monitoring scripts).

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6811085

R=dvyukov
CC=golang-dev
https://golang.org/cl/6733058

R=rsc
CC=golang-dev
https://golang.org/cl/6569057

   PauseNs is a circular buffer of recent pause times, and the
most recent one is at [((NumGC-1)+256)%256].

   Also fix comments cross-linking the Go and C definition of
various structs.

R=golang-dev, rsc, bradfitz
CC=golang-dev
https://golang.org/cl/6657047

R=0xe2.0x9a.0x9b, minux.ma, iant, dave
CC=golang-dev
https://golang.org/cl/6654052

This is a part of a bigger change that adds data race detection feature:
https://golang.org/cl/6456044

R=rsc
CC=gobot, golang-dev
https://golang.org/cl/6535050

R=rsc
CC=golang-dev
https://golang.org/cl/6554060

This CL makes the runtime understand that the type of
the len or cap of a map, slice, or string is 'int', not 'int32',
and it is also careful to distinguish between function arguments
and results of type 'int' vs type 'int32'.

In the runtime, the new typedefs 'intgo' and 'uintgo' refer
to Go int and uint. The C types int and uint continue to be
unavailable (cause intentional compile errors).

This CL does not change the meaning of int, but it should make
the eventual change of the meaning of int on amd64 a bit
smoother.

Update #2188.

R=iant, r, dave, remyoudompheng
CC=golang-dev
https://golang.org/cl/6551067

It will be required for scheduler that maintains
GOMAXPROCS MCache's.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/6350062

linux/arm OMAP4 pandaboard

benchmark                 old ns/op    new ns/op    delta
BenchmarkBinaryTree17   68723297000  37026214000  -46.12%
BenchmarkFannkuch11     34962402000  35958435000   +2.85%
BenchmarkGobDecode        137298600    124182150   -9.55%
BenchmarkGobEncode         60717160     60006700   -1.17%
BenchmarkGzip            5647156000   5550873000   -1.70%
BenchmarkGunzip          1196350000   1198670000   +0.19%
BenchmarkJSONEncode       863012800    782898000   -9.28%
BenchmarkJSONDecode      3312989000   2781800000  -16.03%
BenchmarkMandelbrot200     45727540     45703120   -0.05%
BenchmarkParse             74781800     59990840  -19.78%
BenchmarkRevcomp          140043650    139462300   -0.42%
BenchmarkTemplate        6467682000   5832153000   -9.83%

benchmark                  old MB/s     new MB/s  speedup
BenchmarkGobDecode             5.59         6.18    1.11x
BenchmarkGobEncode            12.64        12.79    1.01x
BenchmarkGzip                  3.44         3.50    1.02x
BenchmarkGunzip               16.22        16.19    1.00x
BenchmarkJSONEncode            2.25         2.48    1.10x
BenchmarkJSONDecode            0.59         0.70    1.19x
BenchmarkParse                 0.77         0.97    1.26x
BenchmarkRevcomp              18.15        18.23    1.00x
BenchmarkTemplate              0.30         0.33    1.10x

darwin/386 core duo

benchmark                 old ns/op    new ns/op    delta
BenchmarkBinaryTree17   10591616577   9678245733   -8.62%
BenchmarkFannkuch11     10758473315  10749303846   -0.09%
BenchmarkGobDecode         34379785     34121250   -0.75%
BenchmarkGobEncode         23523721     23475750   -0.20%
BenchmarkGzip            2486191492   2446539568   -1.59%
BenchmarkGunzip           444179328    444250293   +0.02%
BenchmarkJSONEncode       221138507    219757826   -0.62%
BenchmarkJSONDecode      1056034428   1048975133   -0.67%
BenchmarkMandelbrot200     19862516     19868346   +0.03%
BenchmarkRevcomp         3742610872   3724821662   -0.48%
BenchmarkTemplate         960283112    944791517   -1.61%

benchmark                  old MB/s     new MB/s  speedup
BenchmarkGobDecode            22.33        22.49    1.01x
BenchmarkGobEncode            32.63        32.69    1.00x
BenchmarkGzip                  7.80         7.93    1.02x
BenchmarkGunzip               43.69        43.68    1.00x
BenchmarkJSONEncode            8.77         8.83    1.01x
BenchmarkJSONDecode            1.84         1.85    1.01x
BenchmarkRevcomp              67.91        68.24    1.00x
BenchmarkTemplate              2.02         2.05    1.01x

R=rsc, 0xe2.0x9a.0x9b, mirtchovski
CC=golang-dev, minux.ma
https://golang.org/cl/6297047

R=rsc
CC=golang-dev
https://golang.org/cl/6285047

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6206056

+move zeroization out of the heap mutex

R=golang-dev, iant, rsc
CC=golang-dev
https://golang.org/cl/6094050

If it didn't reach the limit, we can try extending the arena
before resorting to random memory mappings and praying for the
kernel to be kind.

Fixes #3173.

R=rsc, rsc
CC=golang-dev
https://golang.org/cl/5725045

For Brad.
Now FreeBSD/386 binaries run on nearlyfreespeech.net.

Fixes #2302.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5700060

cc: add #pragma textflag to set it
runtime: mark mheap to go into noptr-bss.
        remove special case in garbage collector

Remove the ARM from.flag field created by CL 5687044.
The DUPOK flag was already in p->reg, so keep using that.

Otherwise test/nilptr.go creates a very large binary.
Should fix the arm build.
Diagnosed by minux.ma; replacement for CL 5690044.

R=golang-dev, minux.ma, r
CC=golang-dev
https://golang.org/cl/5686060

Delete Alloc, Free, Lookup, Semacquire, Semrelease

Fixes #2955.

R=golang-dev, r, bradfitz
CC=golang-dev
https://golang.org/cl/5675093

R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5642068

R=rsc
CC=golang-dev
https://golang.org/cl/5642064

On 64 bit UML it is not possible to reserve memory at 0xF8<<32.
Detect when linux cannot use these high virtual memory addresses
and drop back to the 32 bit memory allocator.

R=rsc, cw
CC=golang-dev
https://golang.org/cl/5634050

R=golang-dev
CC=golang-dev
https://golang.org/cl/5529059

Collapse the arch,os-specific directories into the main directory
by renaming xxx/foo.c to foo_xxx.c, and so on.

There are no substantial edits here, except to the Makefile.
The assumption is that the Go tool will #define GOOS_darwin
and GOARCH_amd64 and will make any file named something
like signals_darwin.h available as signals_GOOS.h during the
build.  This replaces what used to be done with -I$(GOOS).

There is still work to be done to make runtime build with
standard tools, but this is a big step.  After this we will have
to write a script to generate all the generated files so they
can be checked in (instead of generated during the build).

R=r, iant, r, lucio.dere
CC=golang-dev
https://golang.org/cl/5490053

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5284044

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5151043

Linux/amd64, 2 x Intel Xeon E5620, 8 HT cores, 2.40GHz
benchmark                    old ns/op    new ns/op    delta
BenchmarkFinalizer              420.00       261.00  -37.86%
BenchmarkFinalizer-2            985.00       201.00  -79.59%
BenchmarkFinalizer-4           1077.00       244.00  -77.34%
BenchmarkFinalizer-8           1155.00       180.00  -84.42%
BenchmarkFinalizer-16          1182.00       184.00  -84.43%

BenchmarkFinalizerRun          2128.00      1378.00  -35.24%
BenchmarkFinalizerRun-2        1655.00      1418.00  -14.32%
BenchmarkFinalizerRun-4        1634.00      1522.00   -6.85%
BenchmarkFinalizerRun-8        2213.00      1581.00  -28.56%
BenchmarkFinalizerRun-16       2424.00      1599.00  -34.03%

Darwin/amd64, Intel L9600, 2 cores, 2.13GHz
benchmark                    old ns/op    new ns/op    delta
BenchmarkChanCreation          1451.00       926.00  -36.18%
BenchmarkChanCreation-2        3124.00      1412.00  -54.80%
BenchmarkChanCreation-4        6121.00...

The malloc sample trigger was not being set in a
new m, so the first allocation in each new m - the
goroutine structure - was being sampled with
probability 1 instead of probability sizeof(G)/rate,
an oversampling of about 5000x for the default
rate of 1 MB.  This bug made pprof graphs show
far more G allocations than there actually were.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5224041

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4963050

Avoid touching centralized state during
memory manager opreations.

R=rsc
CC=golang-dev
https://golang.org/cl/4766042

Standard-sized stack frames use plain malloc/free
instead of centralized lock-protected FixAlloc.
Benchmark results on HP Z600 (2 x Xeon E5620, 8 HT cores, 2.40GHz)
are as follows:
benchmark                                        old ns/op    new ns/op    delta
BenchmarkStackGrowth                               1045.00       949.00   -9.19%
BenchmarkStackGrowth-2                             3450.00       800.00  -76.81%
BenchmarkStackGrowth-4                             5076.00       513.00  -89.89%
BenchmarkStackGrowth-8                             7805.00       471.00  -93.97%
BenchmarkStackGrowth-16                           11751.00       321.00  -97.27%

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4657091

Use machine-local random number generator instead of
racy global ones.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4674049

R=ken2
CC=golang-dev
https://golang.org/cl/4640045

R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/4523047

runtime: memory allocated by OS not in usable range
runtime: out of memory: cannot allocate 1114112-byte block (2138832896 in use)
throw: out of memory

runtime.throw+0x40 /Users/rsc/g/go/src/pkg/runtime/runtime.c:102
        runtime.throw(0x1fffd, 0x101)
runtime.mallocgc+0x2af /Users/rsc/g/go/src/pkg/runtime/malloc.c:60
        runtime.mallocgc(0x100004, 0x0, 0x1, 0x1, 0xc093, ...)
runtime.mal+0x40 /Users/rsc/g/go/src/pkg/runtime/malloc.c:289
        runtime.mal(0x100004, 0x20bc4)
runtime.new+0x26 /Users/rsc/g/go/src/pkg/runtime/malloc.c:296
        runtime.new(0x100004, 0x8fe84000, 0x20bc4)
main.main+0x29 /Users/rsc/x.go:11
        main.main()
runtime.mainstart+0xf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:93
        runtime.mainstart()
runtime.goexit /Users/rsc/g/go/src/pkg/runtime/proc.c:178
        runtime.goexit()
----- goroutine created by -----
_rt0_386+0xbf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:80

R=iant, r
CC=golang-dev
https://golang.org/cl/4444073

Avoids deadlocks like the one below, in which a stack split happened
in order to call lock(&stacks), but then the stack unsplit cannot run
because stacks is now locked.

The only code calling stackalloc that wasn't on a scheduler
stack already was malg, which creates a new goroutine.

runtime.futex+0x23 /home/rsc/g/go/src/pkg/runtime/linux/amd64/sys.s:139
       runtime.futex()
futexsleep+0x50 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:51
       futexsleep(0x5b0188, 0x300000003, 0x100020000, 0x4159e2)
futexlock+0x85 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:119
       futexlock(0x5b0188, 0x5b0188)
runtime.lock+0x56 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:158
       runtime.lock(0x5b0188, 0x7f0d27b4a000)
runtime.stackfree+0x4d /home/rsc/g/go/src/pkg/runtime/malloc.goc:336
       runtime.stackfree(0x7f0d27b4a000, 0x1000, 0x8, 0x7fff37e1e218)
runtime.oldstack+0xa6 /home/rsc/g/go/src/pkg/runtime/proc.c:705
       runtime.oldstack()
runtime.lessstack+0x22 /home/rsc/g/go/src/pkg/runtime/amd64/asm.s:224
       runtime.lessstack()
----- lessstack called from goroutine 2 -----
runtime.lock+0x56 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:158
       runtime.lock(0x5b0188, 0x40a5e2)
runtime.stackalloc+0x55 /home/rsc/g/go/src/pkg/runtime/malloc.c:316
       runtime.stackalloc(0x1000, 0x4055b0)
runtime.malg+0x3d /home/rsc/g/go/src/pkg/runtime/proc.c:803
       runtime.malg(0x1000, 0x40add9)
runtime.newproc1+0x12b /home/rsc/g/go/src/pkg/runtime/proc.c:854
       runtime.newproc1(0xf840027440, 0x7f0d27b49230, 0x0, 0x49f238, 0x40, ...)
runtime.newproc+0x2f /home/rsc/g/go/src/pkg/runtime/proc.c:831
       runtime.newproc(0x0, 0xf840027440, 0xf800000010, 0x44b059)
...

R=r, r2
CC=golang-dev
https://golang.org/cl/4216045