Skip to content

G
go
Switch branch/tag
  1. 08 May, 2015 4 commits
  3. 07 May, 2015 19 commits
  5. 06 May, 2015 17 commits
    • Shenghou Ma's avatar
      go/build: enable cgo by default on iOS · 4a8dbaa4
      Shenghou Ma authored 
      Otherwise misc/cgo/test won't be tested on iOS.

Change-Id: I7ee78c825b0bb092c7a8b2c2ece5a6eda2f6cf95
Reviewed-on: https://go-review.googlesource.com/9643Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      4a8dbaa4
    • Ian Lance Taylor's avatar
      cmd/cgo: readability improvements to generated _cgo_export.h · 2f9acc13
      Ian Lance Taylor authored 
      Also copy doc comments from Go code to _cgo_export.h.

This is a step toward installing this generated file when using
-buildmode=c-archive or c-shared, so that C code can #include it.

Change-Id: I3a243f7b386b58ec5c5ddb9a246bb9f9eddc5fb8
Reviewed-on: https://go-review.googlesource.com/9790Reviewed-by: default avatarMinux Ma <minux@golang.org>
Reviewed-by: default avatarDavid Crawshaw <crawshaw@golang.org>
      2f9acc13
    • Rob Pike's avatar
      cmd/doc: add type-bound vars to global vars list · da4fc529
      Rob Pike authored 
      Already done for constants and funcs, but I didn't realize that some
global vars were also not in the global list. This fixes

	go doc build.Default

Change-Id: I768bde13a400259df3e46dddc9f58c8f0e993c72
Reviewed-on: https://go-review.googlesource.com/9764Reviewed-by: default avatarAndrew Gerrand <adg@golang.org>
      da4fc529
    • Rob Pike's avatar
      testing: document that Log and Logf always print in benchmarks · e9827f62
      Rob Pike authored 
      Fixes #10713.

Change-Id: Ifdafc340ae3bba751236f0482246c568346a569c
Reviewed-on: https://go-review.googlesource.com/9763Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      e9827f62
    • Austin Clements's avatar
      runtime: use heap scan size as estimate of GC scan work · 17db6e04
      Austin Clements authored 
      Currently, the GC uses a moving average of recent scan work ratios to
estimate the total scan work required by this cycle. This is in turn
used to compute how much scan work should be done by mutators when
they allocate in order to perform all expected scan work by the time
the allocated heap reaches the heap goal.

However, our current scan work estimate can be arbitrarily wrong if
the heap topography changes significantly from one cycle to the
next. For example, in the go1 benchmarks, at the beginning of each
benchmark, the heap is dominated by a 256MB no-scan object, so the GC
learns that the scan density of the heap is very low. In benchmarks
that then rapidly allocate pointer-dense objects, by the time of the
next GC cycle, our estimate of the scan work can be too low by a large
factor. This in turn lets the mutator allocate faster than the GC can
collect, allowing it to get arbitrarily far ahead of the scan work
estimate, which leads to very long GC cycles with very little mutator
assist that can overshoot the heap goal by large margins. This is
particularly easy to demonstrate with BinaryTree17:

$ GODEBUG=gctrace=1 ./go1.test -test.bench BinaryTree17
gc #1 @0.017s 2%: 0+0+0+0+0 ms clock, 0+0+0+0/0/0+0 ms cpu, 4->262->262 MB, 4 MB goal, 1 P
gc #2 @0.026s 3%: 0+0+0+0+0 ms clock, 0+0+0+0/0/0+0 ms cpu, 262->262->262 MB, 524 MB goal, 1 P
testing: warning: no tests to run
PASS
BenchmarkBinaryTree17	gc #3 @1.906s 0%: 0+0+0+0+7 ms clock, 0+0+0+0/0/0+7 ms cpu, 325->325->287 MB, 325 MB goal, 1 P (forced)
gc #4 @12.203s 20%: 0+0+0+10067+10 ms clock, 0+0+0+0/2523/852+10 ms cpu, 430->2092->1950 MB, 574 MB goal, 1 P
       1       9150447353 ns/op

Change this estimate to instead use the *current* scannable heap
size. This has the advantage of being based solely on the current
state of the heap, not on past densities or reachable heap sizes, so
it isn't susceptible to falling behind during these sorts of phase
changes. This is strictly an over-estimate, but it's better to
over-estimate and get more assist than necessary than it is to
under-estimate and potentially spiral out of control. Experiments with
scaling this estimate back showed no obvious benefit for mutator
utilization, heap size, or assist time.

This new estimate has little effect for most benchmarks, including
most go1 benchmarks, x/benchmarks, and the 6g benchmark. It has a huge
effect for benchmarks that triggered the bad pacer behavior:

name                   old mean              new mean              delta
BinaryTree17            10.0s × (1.00,1.00)    3.5s × (0.98,1.01)  -64.93% (p=0.000)
Fannkuch11              2.74s × (1.00,1.01)   2.65s × (1.00,1.00)   -3.52% (p=0.000)
FmtFprintfEmpty        56.4ns × (0.99,1.00)  57.8ns × (1.00,1.01)   +2.43% (p=0.000)
FmtFprintfString        187ns × (0.99,1.00)   185ns × (0.99,1.01)   -1.19% (p=0.010)
FmtFprintfInt           184ns × (1.00,1.00)   183ns × (1.00,1.00)  (no variance)
FmtFprintfIntInt        321ns × (1.00,1.00)   315ns × (1.00,1.00)   -1.80% (p=0.000)
FmtFprintfPrefixedInt   266ns × (1.00,1.00)   263ns × (1.00,1.00)   -1.22% (p=0.000)
FmtFprintfFloat         353ns × (1.00,1.00)   353ns × (1.00,1.00)   -0.13% (p=0.035)
FmtManyArgs            1.21µs × (1.00,1.00)  1.19µs × (1.00,1.00)   -1.33% (p=0.000)
GobDecode              9.69ms × (1.00,1.00)  9.59ms × (1.00,1.00)   -1.07% (p=0.000)
GobEncode              7.89ms × (0.99,1.01)  7.74ms × (1.00,1.00)   -1.92% (p=0.000)
Gzip                    391ms × (1.00,1.00)   392ms × (1.00,1.00)     ~    (p=0.522)
Gunzip                 97.1ms × (1.00,1.00)  97.0ms × (1.00,1.00)   -0.10% (p=0.000)
HTTPClientServer       55.7µs × (0.99,1.01)  56.7µs × (0.99,1.01)   +1.81% (p=0.001)
JSONEncode             19.1ms × (1.00,1.00)  19.0ms × (1.00,1.00)   -0.85% (p=0.000)
JSONDecode             66.8ms × (1.00,1.00)  66.9ms × (1.00,1.00)     ~    (p=0.288)
Mandelbrot200          4.13ms × (1.00,1.00)  4.12ms × (1.00,1.00)   -0.08% (p=0.000)
GoParse                3.97ms × (1.00,1.01)  4.01ms × (1.00,1.00)   +0.99% (p=0.000)
RegexpMatchEasy0_32     114ns × (1.00,1.00)   115ns × (0.99,1.00)     ~    (p=0.070)
RegexpMatchEasy0_1K     376ns × (1.00,1.00)   376ns × (1.00,1.00)     ~    (p=0.900)
RegexpMatchEasy1_32    94.9ns × (1.00,1.00)  96.3ns × (1.00,1.01)   +1.53% (p=0.001)
RegexpMatchEasy1_1K     568ns × (1.00,1.00)   567ns × (1.00,1.00)   -0.22% (p=0.001)
RegexpMatchMedium_32    159ns × (1.00,1.00)   159ns × (1.00,1.00)     ~    (p=0.178)
RegexpMatchMedium_1K   46.4µs × (1.00,1.00)  46.6µs × (1.00,1.00)   +0.29% (p=0.000)
RegexpMatchHard_32     2.37µs × (1.00,1.00)  2.37µs × (1.00,1.00)     ~    (p=0.722)
RegexpMatchHard_1K     71.1µs × (1.00,1.00)  71.2µs × (1.00,1.00)     ~    (p=0.229)
Revcomp                 565ms × (1.00,1.00)   562ms × (1.00,1.00)   -0.52% (p=0.000)
Template               81.0ms × (1.00,1.00)  80.2ms × (1.00,1.00)   -0.97% (p=0.000)
TimeParse               380ns × (1.00,1.00)   380ns × (1.00,1.00)     ~    (p=0.148)
TimeFormat              405ns × (0.99,1.00)   385ns × (0.99,1.00)   -5.00% (p=0.000)

Change-Id: I11274158bf3affaf62662e02de7af12d5fb789e4
Reviewed-on: https://go-review.googlesource.com/9696Reviewed-by: default avatarRuss Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
      17db6e04
    • Austin Clements's avatar
      runtime: track "scannable" bytes of heap · 3be3cbd5
      Austin Clements authored 
      This tracks the number of scannable bytes in the allocated heap. That
is, bytes that the garbage collector must scan before reaching the
last pointer field in each object.

This will be used to compute a more robust estimate of the GC scan
work.

Change-Id: I1eecd45ef9cdd65b69d2afb5db5da885c80086bb
Reviewed-on: https://go-review.googlesource.com/9695Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      3be3cbd5
    • Austin Clements's avatar
      runtime: include scalar slots in GC scan work metric · 53c53984
      Austin Clements authored 
      The garbage collector predicts how much "scan work" must be done in a
cycle to determine how much work should be done by mutators when they
allocate. Most code doesn't care what units the scan work is in: it
simply knows that a certain amount of scan work has to be done in the
cycle. Currently, the GC uses the number of pointer slots scanned as
the scan work on the theory that this is the bulk of the time spent in
the garbage collector and hence reflects real CPU resource usage.
However, this metric is difficult to estimate at the beginning of a
cycle.

Switch to counting the total number of bytes scanned, including both
pointer and scalar slots. This is still less than the total marked
heap since it omits no-scan objects and no-scan tails of objects. This
metric may not reflect absolute performance as well as the count of
scanned pointer slots (though it still takes time to scan scalar
fields), but it will be much easier to estimate robustly, which is
more important.

Change-Id: Ie3a5eeeb0384a1ca566f61b2f11e9ff3a75ca121
Reviewed-on: https://go-review.googlesource.com/9694Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      53c53984
    • Austin Clements's avatar
      runtime: dispose gcWork caches before updating controller state · c4931a84
      Austin Clements authored 
      Currently, we only flush the per-P gcWork caches in gcMark, at the
beginning of mark termination. This is necessary to ensure that no
work is held up in these caches.

However, this flush happens after we update the GC controller state,
which depends on statistics about marked heap size and scan work that
are only updated by this flush. Hence, the controller is missing the
bulk of heap marking and scan work. This bug was introduced in commit
1b4025f4, which introduced the per-P gcWork caches.

Fix this by flushing these caches before we update the GC controller
state. We continue to flush them at the beginning of mark termination
as well to be robust in case any write barriers happened between the
previous flush and entering mark termination, but this should be a
no-op.

Change-Id: I8f0f91024df967ebf0c616d1c4f0c339c304ebaa
Reviewed-on: https://go-review.googlesource.com/9646Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      c4931a84
    • Brad Fitzpatrick's avatar
      time: deflake TestAfterQueuing · b4bc7b44
      Brad Fitzpatrick authored 
      Ramp up the delay on subsequent attempts. Fast builders have the same delay.

Not a perfect fix, but should make it better. And this easy.

Fixes #9903 maybe
Fixes #10680 maybe

Change-Id: I967380c2cb8196e6da9a71116961229d37b36335
Reviewed-on: https://go-review.googlesource.com/9795Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      b4bc7b44
    • Brad Fitzpatrick's avatar
      os: eradicate smallpox after test · ec87dbf9
      Brad Fitzpatrick authored 
      Otherwise:

$ go test  -short -cpu=1,1,2,2
--- FAIL: TestLookupEnv (0.00s)
        env_test.go:102: SMALLPOX="virus"
--- FAIL: TestLookupEnv-2 (0.00s)
        env_test.go:102: SMALLPOX="virus"
--- FAIL: TestLookupEnv-2 (0.00s)
        env_test.go:102: SMALLPOX="virus"

Change-Id: Ic1f6dd1bae3c79c4f7da02bc8c30b5e599627a82
Reviewed-on: https://go-review.googlesource.com/9794Reviewed-by: default avatarRob Pike <r@golang.org>
      ec87dbf9
    • Brad Fitzpatrick's avatar
      net: always use cgo for DNS on Android · 7165c9b3
      Brad Fitzpatrick authored 
      Android has (had?) its own local DNS resolver daemon, also my fault:

https://android.googlesource.com/platform/system/netd/+/007e987fee7e815e0c4bc820f434a632b7a69a9d

And you access that via libc, not DNS.

Fixes #10714

Change-Id: Iaff752872ce19bb5c7771ab048fd50e3f72cb73c
Reviewed-on: https://go-review.googlesource.com/9793Reviewed-by: default avatarDavid Crawshaw <crawshaw@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      7165c9b3
    • Rob Pike's avatar
      doc/go1.5.txt: LookupEnv · 6fd387b3
      Rob Pike authored 
      Change-Id: Iff27fa0ca50fe9e41d811d30df41fc2d3057aa1d
Reviewed-on: https://go-review.googlesource.com/9792Reviewed-by: default avatarRob Pike <r@golang.org>
      6fd387b3
    • Rob Pike's avatar
      cmd/doc: if no top-level symbols match, look for methods · 9de28cf5
      Rob Pike authored 
      Improving the usability further.

Before:

$ go doc bytes.Read
doc: symbol Read not present in package bytes installed in "bytes"
$

After:
$ go doc bytes.Read
func (b *Buffer) Read(p []byte) (n int, err error)
    Read reads the next len(p) bytes from the buffer or until the buffer is drained.
    The return value n is the number of bytes read. If the buffer has no data to
    return, err is io.EOF (unless len(p) is zero); otherwise it is nil.
func (r *Reader) Read(b []byte) (n int, err error)
$

Change-Id: I646511fada138bd09e9b39820da01a5ccef4a90f
Reviewed-on: https://go-review.googlesource.com/9656Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      9de28cf5
    • Burcu Dogan's avatar
      CONTRIBUTORS: add Burcu Dogan's personal mail · 5e80fc64
      Burcu Dogan authored 
      Change-Id: I2bc92f6d33db44f96df4219e6144393d5150fe0f
Reviewed-on: https://go-review.googlesource.com/9785Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      5e80fc64
    • Rob Pike's avatar
      os: rewrite LookupEnv's test · 072a2633
      Rob Pike authored 
      GOROOT is not dependably set.

When I first wrote this test, I thought it was a waste of time
because the function can't fail if the other environment functions
work, but I didn't want to add functionality without testing it.
Of course, the test broke, and I learned something: GOROOT is not
set on iOS or, to put it more broadly, the world continues to
surprise me with its complexity and horror, such as a version of
cat with syntax coloring.

In that vein, I built this test around smallpox.

Change-Id: Ifa6c218a927399d05c47954fdcaea1015e558fb6
Reviewed-on: https://go-review.googlesource.com/9791Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      072a2633
    • Rick Hudson's avatar
      runtime: remove unused GC times from api.next · f09a660e
      Rick Hudson authored 
      Updates api boilerplate in seperate CL see commit 18453145 for code changes.
Fixes #10462

Change-Id: I4e28dbdcdd693688835bcd1d4b0224454aa7154d
Reviewed-on: https://go-review.googlesource.com/9784Reviewed-by: default avatarAustin Clements <austin@google.com>
      f09a660e
    • Rick Hudson's avatar
      runtime: remove unused GC timers · 18453145
      Rick Hudson authored 
      During development some tracing routines were added that are not
needed in the release. These included GCstarttimes, GCendtimes, and
GCprinttimes.
Fixes #10462

Change-Id: I0788e6409d61038571a5ae0cbbab793102df0a65
Reviewed-on: https://go-review.googlesource.com/9689Reviewed-by: default avatarAustin Clements <austin@google.com>
      18453145
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7