Skip to content

G
golang
Switch branch/tag
  1. 23 Apr, 2015 2 commits
  3. 22 Apr, 2015 22 commits
  5. 21 Apr, 2015 16 commits
    • Josh Bleecher Snyder's avatar
      math/big: test that subVW and addVW work with arbitrary y · 91f2db3c
      Josh Bleecher Snyder authored 
      Fixes #10525.

Change-Id: I92dc87f5d6db396d8dde2220fc37b7093b772d81
Reviewed-on: https://go-review.googlesource.com/9210Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      91f2db3c
    • Ian Lance Taylor's avatar
      misc/cgo/testcshared: add c-shared test with no exports · e589e080
      Ian Lance Taylor authored 
      The purpose of this test is to make sure that -buildmode=c-shared
works even when the shared library can be built without invoking cgo.

Change-Id: Id6f95af755992b209aff770440ca9819b74113ab
Reviewed-on: https://go-review.googlesource.com/9166Reviewed-by: 's avatarDavid Crawshaw <crawshaw@golang.org>
      e589e080
    • Alan Donovan's avatar
      Revert "go/internal/gcimporter: populate (*types.Package).Imports" · a6083775
      Alan Donovan authored 
      This reverts commit 8d7d02f1.

Reverted because it breaks go/build's "deps" test.

Change-Id: I61db6b2431b3ba0d2b3ece5bab7a04194239c34b
Reviewed-on: https://go-review.googlesource.com/9174Reviewed-by: 's avatarAlan Donovan <adonovan@google.com>
      a6083775
    • Alan Donovan's avatar
      go/internal/gcimporter: populate (*types.Package).Imports · 8d7d02f1
      Alan Donovan authored 
      This is an upstream change to the tools repo:
https://go-review.googlesource.com/#/c/8924/

Change-Id: I01fb1b2e9ec834354994c544f65c8ec8267c9626
Reviewed-on: https://go-review.googlesource.com/8954
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      8d7d02f1
    • Ian Lance Taylor's avatar
      cmd/go: depend on runtime/cgo if external linking mode is forced · af161c57
      Ian Lance Taylor authored 
      In external linking mode, the linker automatically imports
runtime/cgo.  When the user uses non-standard compilation options,
they have to know to run go install runtime/cgo.  When the go tool
adds non-standard compilation options itself, we can't force the user
to do that.  So add the dependency ourselves.

Bad news: we don't currently have a clean way to know whether we are
going to use external linking mode.  This CL duplicates logic split
between cmd/6l and cmd/internal/ld.

Good news: adding an unnecessary dependency on runtime/cgo does no
real harm.  We aren't going to force the linker to pull it in, we're
just going to build it so that its available if the linker wants it.

Change-Id: Ide676339d4e8b1c3d9792884a2cea921abb281b7
Reviewed-on: https://go-review.googlesource.com/9115Reviewed-by: 's avatarDavid Crawshaw <crawshaw@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
      af161c57
    • Sebastien Binet's avatar
      reflect: use arrayAt consistently · e00e6563
      Sebastien Binet authored 
      This change refactors reflect.Value to consistently use arrayAt when an element
of an array of bytes is indexed.

This effectively replaces:
 arr := unsafe.Pointer(...)
 arri := unsafe.Pointer(uintptr(arr) + uintptr(i)*elementSize)

with:
 arr := unsafe.Pointer(...)
 arri := arrayAt(arr, i, elementSize)

Change-Id: I53ffd0d6de693b43d5c10c0aa4cd6d4f5e95a1e3
Reviewed-on: https://go-review.googlesource.com/9183Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: 's avatarKeith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      e00e6563
    • Josh Bleecher Snyder's avatar
      cmd/internal/obj: reuse the varint encoding buffer · 873483c6
      Josh Bleecher Snyder authored 
      This reduces the number of allocations in the compiler
while building the stdlib by 15.66%.

No functional changes. Passes toolstash -cmp.

Change-Id: Ia21b37134a8906a4e23d53fdc15235b4aa7bbb34
Reviewed-on: https://go-review.googlesource.com/9085Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      873483c6
    • Sebastien Binet's avatar
      doc/go1.5.txt: add reflect.ArrayOf · 3c939b53
      Sebastien Binet authored 
      Change-Id: I89704249218d4fdba11463c239c69143f8ad0051
Reviewed-on: https://go-review.googlesource.com/9185Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      3c939b53
    • Austin Clements's avatar
      runtime: assist harder if GC exceeds the estimated marked heap · 170fb100
      Austin Clements authored 
      Currently, the GC controller computes the mutator assist ratio at the
beginning of the cycle by estimating that the marked heap size this
cycle will be the same as it was the previous cycle. It then uses that
assist ratio for the rest of the cycle. However, this means that if
the mutator is quickly growing its reachable heap, the heap size is
likely to exceed the heap goal and currently there's no additional
pressure on mutator assists when this happens. For example, 6g (with
GOMAXPROCS=1) frequently exceeds the goal heap size by ~25% because of
this.

This change makes GC revise its work estimate and the resulting assist
ratio every 10ms during the concurrent mark. Instead of
unconditionally using the marked heap size from the last cycle as an
estimate for this cycle, it takes the minimum of the previously marked
heap and the currently marked heap. As a result, as the cycle
approaches or exceeds its heap goal, this will increase the assist
ratio to put more pressure on the mutator assist to bring the cycle to
an end. For 6g, this causes the GC to always finish within 5% and
often within 1% of its heap goal.

Change-Id: I4333b92ad0878c704964be42c655c38a862b4224
Reviewed-on: https://go-review.googlesource.com/9070Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
      170fb100
    • Austin Clements's avatar
      runtime: fix background marking at 25% utilization · e0c3d85f
      Austin Clements authored 
      Currently, in accordance with the GC pacing proposal, we schedule
background marking with a goal of achieving 25% utilization *total*
between mutator assists and background marking. This is stricter than
was set out in the Go 1.5 proposal, which suggests that the garbage
collector can use 25% just for itself and anything the mutator does to
help out is on top of that. It also has several technical
drawbacks. Because mutator assist time is constantly changing and we
can't have instantaneous information on background marking time, it
effectively requires hitting a moving target based on out-of-date
information. This works out in the long run, but works poorly for
short GC cycles and on short time scales. Also, this requires
time-multiplexing all Ps between the mutator and background GC since
the goal utilization of background GC constantly fluctuates. This
results in a complicated scheduling algorithm, poor affinity, and
extra overheads from context switching.

This change modifies the way we schedule and run background marking so
that background marking always consumes 25% of GOMAXPROCS and mutator
assist is in addition to this. This enables a much more robust
scheduling algorithm where we pre-determine the number of Ps we should
dedicate to background marking as well as the utilization goal for a
single floating "remainder" mark worker.

Change-Id: I187fa4c03ab6fe78012a84d95975167299eb9168
Reviewed-on: https://go-review.googlesource.com/9013Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      e0c3d85f
    • Austin Clements's avatar
      runtime: finish sweeping before concurrent GC starts · 24a7252e
      Austin Clements authored 
      Currently, the concurrent sweep follows a 1:1 rule: when allocation
needs a span, it sweeps a span (likewise, when a large allocation
needs N pages, it sweeps until it frees N pages). This rule worked
well for the STW collector (especially when GOGC==100) because it did
no more sweeping than necessary to keep the heap from growing, would
generally finish sweeping just before GC, and ensured good temporal
locality between sweeping a page and allocating from it.

It doesn't work well with concurrent GC. Since concurrent GC requires
starting GC earlier (sometimes much earlier), the sweep often won't be
done when GC starts. Unfortunately, the first thing GC has to do is
finish the sweep. In the mean time, the mutator can continue
allocating, pushing the heap size even closer to the goal size. This
worked okay with the 7/8ths trigger, but it gets into a vicious cycle
with the GC trigger controller: if the mutator is allocating quickly
and driving the trigger lower, more and more sweep work will be left
to GC; this both causes GC to take longer (allowing the mutator to
allocate more during GC) and delays the start of the concurrent mark
phase, which throws off the GC controller's statistics and generally
causes it to push the trigger even lower.

As an example of a particularly bad case, the garbage benchmark with
GOMAXPROCS=4 and -benchmem 512 (MB) spends the first 0.4-0.8 seconds
of each GC cycle sweeping, during which the heap grows by between
109MB and 252MB.

To fix this, this change replaces the 1:1 sweep rule with a
proportional sweep rule. At the end of GC, GC knows exactly how much
heap allocation will occur before the next concurrent GC as well as
how many span pages must be swept. This change computes this "sweep
ratio" and when the mallocgc asks for a span, the mcentral sweeps
enough spans to bring the swept span count into ratio with the
allocated byte count.

On the benchmark from above, this entirely eliminates sweeping at the
beginning of GC, which reduces the time between startGC readying the
GC goroutine and GC stopping the world for sweep termination to ~100µs
during which the heap grows at most 134KB.

Change-Id: I35422d6bba0c2310d48bb1f8f30a72d29e98c1af
Reviewed-on: https://go-review.googlesource.com/8921Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      24a7252e
    • Austin Clements's avatar
      runtime: make mcache.local_cachealloc a uintptr · 91c80ce6
      Austin Clements authored 
      This field used to decrease with sweeps (and potentially go
negative). Now it is always zero or positive, so change it to a
uintptr so it meshes better with other memory stats.

Change-Id: I6a50a956ddc6077eeaf92011c51743cb69540a3c
Reviewed-on: https://go-review.googlesource.com/8899Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      91c80ce6
    • Austin Clements's avatar
      runtime: proportional response GC trigger controller · a0452a68
      Austin Clements authored 
      Currently, concurrent GC triggers at a fixed 7/8*GOGC heap growth. For
mutators that allocate slowly, this means GC will trigger too early
and run too often, wasting CPU time on GC. For mutators that allocate
quickly, this means GC will trigger too late, causing the program to
exceed the GOGC heap growth goal and/or to exceed CPU goals because of
a high mutator assist ratio.

This change adds a feedback control loop to dynamically adjust the GC
trigger from cycle to cycle. By monitoring the heap growth and GC CPU
utilization from cycle to cycle, this adjusts the Go garbage collector
to target the GOGC heap growth goal and the 25% CPU utilization goal.

Change-Id: Ic82eef288c1fa122f73b69fe604d32cbb219e293
Reviewed-on: https://go-review.googlesource.com/8851Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      a0452a68
    • Austin Clements's avatar
      runtime: multi-threaded, utilization-scheduled background mark · 8d03acce
      Austin Clements authored 
      Currently, the concurrent mark phase is performed by the main GC
goroutine. Prior to the previous commit enabling preemption, this
caused marking to always consume 1/GOMAXPROCS of the available CPU
time. If GOMAXPROCS=1, this meant background GC would consume 100% of
the CPU (effectively a STW). If GOMAXPROCS>4, background GC would use
less than the goal of 25%. If GOMAXPROCS=4, background GC would use
the goal 25%, but if the mutator wasn't using the remaining 75%,
background marking wouldn't take advantage of the idle time. Enabling
preemption in the previous commit made GC miss CPU targets in
completely different ways, but set us up to bring everything back in
line.

This change replaces the fixed GC goroutine with per-P background mark
goroutines. Once started, these goroutines don't go in the standard
run queues; instead, they are scheduled specially such that the time
spent in mutator assists and the background mark goroutines totals 25%
of the CPU time available to the program. Furthermore, this lets
background marking take advantage of idle Ps, which significantly
boosts GC performance for applications that under-utilize the CPU.

This requires also changing how time is reported for gctrace, so this
change splits the concurrent mark CPU time into assist/background/idle
scanning.

This also requires increasing the size of the StackRecord slice used
in a GoroutineProfile test.

Change-Id: I0936ff907d2cee6cb687a208f2df47e8988e3157
Reviewed-on: https://go-review.googlesource.com/8850Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      8d03acce
    • Austin Clements's avatar
      runtime: generally allow preemption during concurrent GC phases · af060c30
      Austin Clements authored 
      Currently, the entire GC process runs with g.m.preemptoff set. In the
concurrent phases, the parts that actually need preemption disabled
are run on a system stack and there's no overall need to stay on the
same M or P during the concurrent phases. Hence, move the setting of
g.m.preemptoff to when we start mark termination, at which point we
really do need preemption disabled.

This dramatically changes the scheduling behavior of the concurrent
mark phase. Currently, since this is non-preemptible, concurrent mark
gets one dedicated P (so 1/GOMAXPROCS utilization). With this change,
the GC goroutine is scheduled like any other goroutine during
concurrent mark, so it gets 1/<runnable goroutines> utilization.

You might think it's not even necessary to set g.m.preemptoff at that
point since the world is stopped, but stackalloc/stackfree use this as
a signal that the per-P pools are not safe to access without
synchronization.

Change-Id: I08aebe8179a7d304650fb8449ff36262b3771099
Reviewed-on: https://go-review.googlesource.com/8839Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      af060c30
    • Austin Clements's avatar
      runtime: track time spent in mutator assists · 100da609
      Austin Clements authored 
      This time is tracked per P and periodically flushed to the global
controller state. This will be used to compute mutator assist
utilization in order to schedule background GC work.

Change-Id: Ib94f90903d426a02cf488bf0e2ef67a068eb3eec
Reviewed-on: https://go-review.googlesource.com/8837Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      100da609