1. 05 May, 2016 8 commits
  2. 04 May, 2016 24 commits
  3. 03 May, 2016 8 commits
    • Brad Fitzpatrick's avatar
      cmd/vet: fix test's dependence on perl · 4d5ac10f
      Brad Fitzpatrick authored
      Change-Id: I774dbd4f90ef271a0969c3c8e65d145669312e3e
      Reviewed-on: https://go-review.googlesource.com/22745
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: default avatarRoss Light <light@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      4d5ac10f
    • Keith Randall's avatar
      cmd/compile: never CSE two memories · b64c7fc6
      Keith Randall authored
      It never makes sense to CSE two ops that generate memory.
      We might as well start those ops off in their own partition.
      
      Fixes #15520
      
      Change-Id: I0091ed51640f2c10cd0117f290b034dde7a86721
      Reviewed-on: https://go-review.googlesource.com/22741Reviewed-by: default avatarJosh Bleecher Snyder <josharian@gmail.com>
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      b64c7fc6
    • Brad Fitzpatrick's avatar
      strings, bytes: fix Reader 0 byte read at EOF · 01182425
      Brad Fitzpatrick authored
      0 byte reads at EOF weren't returning EOF.
      
      Change-Id: I19b5fd5a72e83d49566a230ce4067be03f00d14b
      Reviewed-on: https://go-review.googlesource.com/22740Reviewed-by: default avatarBryan Mills <bcmills@google.com>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      01182425
    • Robert Griesemer's avatar
      cmd/compile: use correct packages when exporting/importing _ (blank) names · 15f7a66f
      Robert Griesemer authored
      1) Blank parameters cannot be accessed so the package doesn't matter.
         Do not export it, and consistently use localpkg when importing a
         blank parameter.
      
      2) More accurately replicate fmt.go and parser.go logic when importing
         a blank struct field. Blank struct fields get exported without
         package qualification.
         (This is actually incorrect, even with the old textual export format,
         but we will fix that in a separate change. See also issue 15514.)
      
      Fixes #15491.
      
      Change-Id: I7978e8de163eb9965964942aee27f13bf94a7c3c
      Reviewed-on: https://go-review.googlesource.com/22714Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      15f7a66f
    • Dmitry Vyukov's avatar
      cmd/trace: make binary argument optional · babdbfb8
      Dmitry Vyukov authored
      1.7 traces embed symbol info and we now generate symbolized pprof profiles,
      so we don't need the binary. Make binary argument optional as 1.5 traces
      still need it.
      
      Change-Id: I65eb13e3d20ec765acf85c42d42a8d7aae09854c
      Reviewed-on: https://go-review.googlesource.com/22410Reviewed-by: default avatarHyang-Ah Hana Kim <hyangah@gmail.com>
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      babdbfb8
    • Dmitry Vyukov's avatar
      runtime: per-P contexts for race detector · caa21475
      Dmitry Vyukov authored
      Race runtime also needs local malloc caches and currently uses
      a mix of per-OS-thread and per-goroutine caches. This leads to
      increased memory consumption. But more importantly cache of
      synchronization objects is per-goroutine and we don't always
      have goroutine context when feeing memory in GC. As the result
      synchronization object descriptors leak (more precisely, they
      can be reused if another synchronization object is recreated
      at the same address, but it does not always help). For example,
      the added BenchmarkSyncLeak has effectively runaway memory
      consumption (based on a real long running server).
      
      This change updates race runtime with support for per-P contexts.
      BenchmarkSyncLeak now stabilizes at ~1GB memory consumption.
      
      Long term, this will allow us to remove race runtime dependency
      on glibc (as malloc is the main cornerstone).
      
      I've also implemented a different scheme to pass P context to
      race runtime: scheduler notified race runtime about association
      between G and P by calling procwire(g, p)/procunwire(g, p).
      But it turned out to be very messy as we have lots of places
      where the association changes (e.g. syscalls). So I dropped it
      in favor of the current scheme: race runtime asks scheduler
      about the current P.
      
      Fixes #14533
      
      Change-Id: Iad10d2f816a44affae1b9fed446b3580eafd8c69
      Reviewed-on: https://go-review.googlesource.com/19970Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      caa21475
    • Dmitry Vyukov's avatar
      runtime: fix CPU underutilization · fcd7c02c
      Dmitry Vyukov authored
      Runqempty is a critical predicate for scheduler. If runqempty spuriously
      returns true, then scheduler can fail to schedule arbitrary number of
      runnable goroutines on idle Ps for arbitrary long time. With the addition
      of runnext runqempty predicate become broken (can spuriously return true).
      Consider that runnext is not nil and the main array is empty. Runqempty
      observes that the array is empty, then it is descheduled for some time.
      Then queue owner pushes another element to the queue evicting runnext
      into the array. Then queue owner pops runnext. Then runqempty resumes
      and observes runnext is nil and returns true. But there were no point
      in time when the queue was empty.
      
      Fix runqempty predicate to not return true spuriously.
      
      Change-Id: Ifb7d75a699101f3ff753c4ce7c983cf08befd31e
      Reviewed-on: https://go-review.googlesource.com/20858Reviewed-by: default avatarAustin Clements <austin@google.com>
      Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      fcd7c02c
    • Michael Hudson-Doyle's avatar
      cmd/cgo: an approach to tsan that works with gcc · 499cd337
      Michael Hudson-Doyle authored
      GCC, unlike clang, does not provide any way for code being compiled to tell if
      -fsanitize-thread was passed. But cgo can look to see if that flag is being
      passed and generate different code in that case.
      
      Fixes #14602
      
      Change-Id: I86cb5318c2e35501ae399618c05af461d1252d2d
      Reviewed-on: https://go-review.googlesource.com/22688
      Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      499cd337