1. 21 Apr, 2015 24 commits
    • 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
    • Austin Clements's avatar
      runtime: proportional mutator assist · 4b2fde94
      Austin Clements authored
      Currently, mutator allocation periodically assists the garbage
      collector by performing a small, fixed amount of scanning work.
      However, to control heap growth, mutators need to perform scanning
      work *proportional* to their allocation rate.
      
      This change implements proportional mutator assists. This uses the
      scan work estimate computed by the garbage collector at the beginning
      of each cycle to compute how much scan work must be performed per
      allocation byte to complete the estimated scan work by the time the
      heap reaches the goal size. When allocation triggers an assist, it
      uses this ratio and the amount allocated since the last assist to
      compute the assist work, then attempts to steal as much of this work
      as possible from the background collector's credit, and then performs
      any remaining scan work itself.
      
      Change-Id: I98b2078147a60d01d6228b99afd414ef857e4fba
      Reviewed-on: https://go-review.googlesource.com/8836Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      4b2fde94
    • Austin Clements's avatar
      runtime: make gcDrainN in terms of scan work · 028f9728
      Austin Clements authored
      Currently, the "n" in gcDrainN is in terms of objects to scan. This is
      used by gchelpwork to perform a limited amount of work on allocation,
      but is a pretty arbitrary way to bound this amount of work since the
      number of objects has little relation to how long they take to scan.
      
      Modify gcDrainN to perform a fixed amount of scan work instead. For
      now, gchelpwork still performs a fairly arbitrary amount of scan work,
      but at least this is much more closely related to how long the work
      will take. Shortly, we'll use this to precisely control the scan work
      performed by mutator assists during allocation to achieve the heap
      size goal.
      
      Change-Id: I3cd07fe0516304298a0af188d0ccdf621d4651cc
      Reviewed-on: https://go-review.googlesource.com/8835Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      028f9728
    • Austin Clements's avatar
      runtime: track background scan work credit · 8e24283a
      Austin Clements authored
      This tracks scan work done by background GC in a global pool. Mutator
      assists will draw on this credit to avoid doing work when background
      GC is staying ahead.
      
      Unlike the other GC controller tracking variables, this will be both
      written and read throughout the cycle. Hence, we can't arbitrarily
      delay updates like we can for scan work and bytes marked. However, we
      still want to minimize contention, so this global credit pool is
      allowed some error from the "true" amount of credit. Background GC
      accumulates credit locally up to a limit and only then flushes to the
      global pool. Similarly, mutator assists will draw from the credit pool
      in batches.
      
      Change-Id: I1aa4fc604b63bf53d1ee2a967694dffdfc3e255e
      Reviewed-on: https://go-review.googlesource.com/8834Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      8e24283a
    • Austin Clements's avatar
      runtime: implement GC scan work estimator · 4e9fc0df
      Austin Clements authored
      This implements tracking the scan work ratio of a GC cycle and using
      this to estimate the scan work that will be required by the next GC
      cycle. Currently this estimate is unused; it will be used to drive
      mutator assists.
      
      Change-Id: I8685b59d89cf1d83eddfc9b30d84da4e3a7f4b72
      Reviewed-on: https://go-review.googlesource.com/8833Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      4e9fc0df
    • Austin Clements's avatar
      runtime: track scan work performed during concurrent mark · 571ebae6
      Austin Clements authored
      This tracks the amount of scan work in terms of scanned pointers
      during the concurrent mark phase. We'll use this information to
      estimate scan work for the next cycle.
      
      Currently this aggregates the work counter in gcWork and dispose
      atomically aggregates this into a global work counter. dispose happens
      relatively infrequently, so the contention on the global counter
      should be low. If this turns out to be an issue, we can reduce the
      number of disposes, and if it's still a problem, we can switch to
      per-P counters.
      
      Change-Id: Iac0364c466ee35fab781dbbbe7970a5f3c4e1fc1
      Reviewed-on: https://go-review.googlesource.com/8832Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      571ebae6
    • Austin Clements's avatar
      runtime: atomic ops for int64 · fb9fd2bd
      Austin Clements authored
      These currently use portable implementations in terms of their uint64
      counterparts.
      
      Change-Id: Icba5f7134cfcf9d0429edabcdd73091d97e5e905
      Reviewed-on: https://go-review.googlesource.com/8831Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      fb9fd2bd
    • Sebastien Binet's avatar
      reflect: implement ArrayOf · 918fdae3
      Sebastien Binet authored
      This change exposes reflect.ArrayOf to create new reflect.Type array
      types at runtime, when given a reflect.Type element.
      
      - reflect: implement ArrayOf
      - reflect: tests for ArrayOf
      - runtime: document that typeAlg is used by reflect and must be kept in
        synchronized
      
      Fixes #5996.
      
      Change-Id: I5d07213364ca915c25612deea390507c19461758
      Reviewed-on: https://go-review.googlesource.com/4111Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      918fdae3
    • Matthew Dempsky's avatar
      runtime/pprof: disable flaky TestTraceFutileWakeup on linux/ppc64le · c0fa9e3f
      Matthew Dempsky authored
      Update #10512.
      
      Change-Id: Ifdc59c3a5d8aba420b34ae4e37b3c2315dd7c783
      Reviewed-on: https://go-review.googlesource.com/9162Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      c0fa9e3f
    • Mikio Hara's avatar
      net: fix possible nil pointer dereference on ReadFrom for windows · 0f6a3ba4
      Mikio Hara authored
      Fixes #10516.
      
      Change-Id: Ia93f53d4e752bbcca6112bc75f6c3dbe30b90dac
      Reviewed-on: https://go-review.googlesource.com/9192Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      0f6a3ba4
    • Mikio Hara's avatar
      net: fix inconsistent error values on Lookup · 0fc582e8
      Mikio Hara authored
      This change fixes inconsistent error values on
      Lookup{Addr,CNAME,Host,IP.MX,NS,Port,SRV,TXT}.
      
      Updates #4856.
      
      Change-Id: I059bc8ffb96ee74dff8a8c4e8e6ae3e4a462a7ef
      Reviewed-on: https://go-review.googlesource.com/9108Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      0fc582e8
    • Mikio Hara's avatar
      net: fix inconsistent error values on Interface · 456cf0f2
      Mikio Hara authored
      This change fixes inconsistent error values on Interfaces,
      InterfaceAddrs, InterfaceBy{Index,Name}, and Addrs and MulticastAddrs
      methods of Interface.
      
      Updates #4856.
      
      Change-Id: I09e65522a22f45c641792d774ebf7a0081b874ad
      Reviewed-on: https://go-review.googlesource.com/9140Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      456cf0f2
    • Mikio Hara's avatar
      net: fix inconsistent error values on setters · 2173a279
      Mikio Hara authored
      This change fixes inconsistent error values on
      Set{Deadline,ReadDeadline,WriteDeadline,ReadBuffer,WriteBuffer} for
      Conn, Listener and PacketConn, and
      Set{KeepAlive,KeepAlivePeriod,Linger,NoDelay} for TCPConn.
      
      Updates #4856.
      
      Change-Id: I34ca5e98f6de72863f85b2527478b20d8d5394dd
      Reviewed-on: https://go-review.googlesource.com/9109Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      2173a279
    • Mikio Hara's avatar
      net: fix inconsistent error values on File · 88511136
      Mikio Hara authored
      This change fixes inconsistent error values on
      File{Conn,Listener,PacketConn} and File method of Conn, Listener.
      
      Updates #4856.
      
      Change-Id: I3197b9277bef0e034427e3a44fa77523acaa2520
      Reviewed-on: https://go-review.googlesource.com/9101Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      88511136
    • Michael Hudson-Doyle's avatar
      cmd/6l, cmd/internal/ld, cmd/internal/obj: remove Xsym/Xadd from compiler's Reloc · 0088ddc3
      Michael Hudson-Doyle authored
      They don't really make any sense on this side of the compiler/linker divide.
      
      Some of the code touching these fields was the support for R_TLS when
      thechar=='6' which turns out to be dead and so I just removed all of that.
      
      Change-Id: I4e265613c4e7fcc30a965fffb7fd5f45017f06f3
      Reviewed-on: https://go-review.googlesource.com/9107
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      0088ddc3
    • Mikio Hara's avatar
      net: add helpers for server testing · 832c5735
      Mikio Hara authored
      Also moves a few server test helpers into mockserver_test.go.
      
      Change-Id: I5a95c9bc6f0c4683751bcca77e26a8586a377466
      Reviewed-on: https://go-review.googlesource.com/9106Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      832c5735
  2. 20 Apr, 2015 16 commits