Skip to content

G
go
Switch branch/tag
  1. 03 Dec, 2013 5 commits
    • Carl Shapiro's avatar
      runtime: move stack scanning into the parallel mark phase · 0368a7ce
      Carl Shapiro authored 
      This change reduces the cost of the stack scanning by frames.
It moves the stack scanning from the serial root enumeration
phase to the parallel tracing phase.  The output that follows
are timings for the issue 6482 benchmark

Baseline

BenchmarkGoroutineSelect	      50	 108027405 ns/op
BenchmarkGoroutineBlocking	      50	  89573332 ns/op
BenchmarkGoroutineForRange	      20	  95614116 ns/op
BenchmarkGoroutineIdle		      20	 122809512 ns/op

Stack scan by frames, non-parallel

BenchmarkGoroutineSelect	      20	 297138929 ns/op
BenchmarkGoroutineBlocking	      20	 301137599 ns/op
BenchmarkGoroutineForRange	      10	 312499469 ns/op
BenchmarkGoroutineIdle		      10	 209428876 ns/op

Stack scan by frames, parallel

BenchmarkGoroutineSelect	      20	 183938431 ns/op
BenchmarkGoroutineBlocking	      20	 170109999 ns/op
BenchmarkGoroutineForRange	      20	 179628882 ns/op
BenchmarkGoroutineIdle		      20	 157541498 ns/op

The remaining performance disparity is due to inefficiencies
in gentraceback and its callees.  The effect was isolated by
using a parallel stack scan where scanstack was modified to do
a conservative scan of the stack segments without gentraceback
followed by a call of gentrackback with a no-op callback.

The output that follows are the top-10 most frequent tops of
stacks as determined by the Linux perf record facility.

Baseline

+  25.19%  gc.test  gc.test            [.] runtime.xchg
+  19.00%  gc.test  gc.test            [.] scanblock
+   8.53%  gc.test  gc.test            [.] scanstack
+   8.46%  gc.test  gc.test            [.] flushptrbuf
+   5.08%  gc.test  gc.test            [.] procresize
+   3.57%  gc.test  gc.test            [.] runtime.chanrecv
+   2.94%  gc.test  gc.test            [.] dequeue
+   2.74%  gc.test  gc.test            [.] addroots
+   2.25%  gc.test  gc.test            [.] runtime.ready
+   1.33%  gc.test  gc.test            [.] runtime.cas64

Gentraceback

+  18.12%  gc.test  gc.test             [.] runtime.xchg
+  14.68%  gc.test  gc.test             [.] scanblock
+   8.20%  gc.test  gc.test             [.] runtime.gentraceback
+   7.38%  gc.test  gc.test             [.] flushptrbuf
+   6.84%  gc.test  gc.test             [.] scanstack
+   5.92%  gc.test  gc.test             [.] runtime.findfunc
+   3.62%  gc.test  gc.test             [.] procresize
+   3.15%  gc.test  gc.test             [.] readvarint
+   1.92%  gc.test  gc.test             [.] addroots
+   1.87%  gc.test  gc.test             [.] runtime.chanrecv

R=golang-dev, dvyukov, rsc
CC=golang-dev
https://golang.org/cl/17410043
      0368a7ce
    • Keith Randall's avatar
      runtime: get rid of concatstring's vararg C argument. · 24699fb0
      Keith Randall authored 
      Pass as a slice of strings instead.  For 2-5 strings, implement
dedicated routines so no slices are needed.

static call counts in the go binary:
 2 strings: 342 occurrences
 3 strings:  98
 4 strings:  30
 5 strings:  13
6+ strings:  14

Why?  C varags, bad for stack scanning and copying.

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/36380043
      24699fb0
    • Keith Randall's avatar
      runtime: fix race detector when map keys/values are passed by pointer. · c0f22945
      Keith Randall authored 
      Now that the map implementation is reading the keys and values from
arbitrary memory (instead of from stack slots), it needs to tell the
race detector when it does so.

Fixes #6875.

R=golang-dev, dave
CC=golang-dev
https://golang.org/cl/36360043
      c0f22945
    • Keith Randall's avatar
      reflect: test to make sure big Zero()-obtained objects are really zero. · 742f755a
      Keith Randall authored 
      Update #6876.

R=dave, bradfitz
CC=golang-dev
https://golang.org/cl/36370043
      742f755a
    • Keith Randall's avatar
      reflect: fix Zero() implementation - not every type has a · e7d899cb
      Keith Randall authored 
      zero object allocated, so we still need to allocate a new
zero area every time.

Fixes #6876.

R=golang-dev
CC=golang-dev
https://golang.org/cl/36320043
      e7d899cb
  3. 02 Dec, 2013 3 commits
  5. 01 Dec, 2013 1 commit
  7. 27 Nov, 2013 1 commit
  9. 25 Nov, 2013 2 commits
  11. 20 Nov, 2013 2 commits
  13. 19 Nov, 2013 3 commits
  15. 18 Nov, 2013 2 commits
  17. 15 Nov, 2013 1 commit
  19. 14 Nov, 2013 2 commits
  21. 13 Nov, 2013 7 commits
  23. 12 Nov, 2013 2 commits
  25. 11 Nov, 2013 2 commits
  27. 08 Nov, 2013 2 commits
  29. 07 Nov, 2013 1 commit
    • Russ Cox's avatar
      cmd/cgo: fix handling of array of pointers when using clang · 6be1cb8c
      Russ Cox authored 
      Clang does not record the "size" field for pointer types,
so we must insert the size ourselves. We were already
doing this, but only for the case of pointer types.
For an array of pointer types, the setting of the size for
the nested pointer type was happening after the computation
of the size of the array type, meaning that the array type
was always computed as 0 bytes. Delay the size computation.

This bug happens on all Clang systems, not just FreeBSD.
Our test checked that cgo wrote something, not that it was correct.
FreeBSD's default clang rejects array[0] as a C struct field,
so it noticed the incorrect sizes. But the sizes were incorrect
everywhere.

Update testcdefs to check the output has the right semantics.

Fixes #6292.

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/22840043
      6be1cb8c
  31. 06 Nov, 2013 1 commit
  33. 05 Nov, 2013 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7