1. 13 Jan, 2016 4 commits
    • David Chase's avatar
      cmd/compile: better modeling of escape across loop levels · e779bfa5
      David Chase authored
      Brief background on "why heap allocate".  Things can be
      forced to the heap for the following reasons:
      
      1) address published, hence lifetime unknown.
      2) size unknown/too large, cannot be stack allocated
      3) multiplicity unknown/too large, cannot be stack allocated
      4) reachable from heap (not necessarily published)
      
      The bug here is a case of failing to enforce 4) when an
      object Y was reachable from a heap allocation X forced
      because of 3).  It was found in the case of a closure
      allocated within a loop (X) and assigned to a variable
      outside the loop (multiplicity unknown) where the closure
      also captured a map (Y) declared outside the loop (reachable
      from heap). Note the variable declared outside the loop (Y)
      is not published, has known size, and known multiplicity
      (one). The only reason for heap allocation is that it was
      reached from a heap allocated item (X), but because that was
      not forced by publication, it has to be tracked by loop
      level, but escape-loop level was not tracked and thus a bug
      results.
      
      The fix is that when a heap allocation is newly discovered,
      use its looplevel as the minimum loop level for downstream
      escape flooding.
      
      Every attempt to generalize this bug to X-in-loop-
      references-Y-outside loop succeeded, so the fix was aimed
      to be general.  Anywhere that loop level forces heap
      allocation, the loop level is tracked.  This is not yet
      tested for all possible X and Y, but it is correctness-
      conservative and because it caused only one trivial
      regression in the escape tests, it is probably also
      performance-conservative.
      
      The new test checks the following:
      1) in the map case, that if fn escapes, so does the map.
      2) in the map case, if fn does not escape, neither does the map.
      3) in the &x case, that if fn escapes, so does &x.
      4) in the &x case, if fn does not escape, neither does &x.
      
      Fixes #13799.
      
      Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb
      Reviewed-on: https://go-review.googlesource.com/18234
      Run-TryBot: David Chase <drchase@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      e779bfa5
    • Michael Hudson-Doyle's avatar
      runtime/internal/atomic: use //go:noinline to prevent inlining, not assembly nop · 04093286
      Michael Hudson-Doyle authored
      A bit cleanuppy for 1.6 maybe, but something I happened to notice.
      
      Change-Id: I70f3b48445f4f527d67f7b202b6171195440b09f
      Reviewed-on: https://go-review.googlesource.com/18550Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      04093286
    • Russ Cox's avatar
      runtime: make NumGoroutine and Stack agree not to include system goroutines · fac8202c
      Russ Cox authored
      [Repeat of CL 18343 with build fixes.]
      
      Before, NumGoroutine counted system goroutines and Stack (usually) didn't show them,
      which was inconsistent and confusing.
      
      To resolve which way they should be consistent, it seems like
      
      	package main
      	import "runtime"
      	func main() { println(runtime.NumGoroutine()) }
      
      should print 1 regardless of internal runtime details. Make it so.
      
      Fixes #11706.
      
      Change-Id: If26749fec06aa0ff84311f7941b88d140552e81d
      Reviewed-on: https://go-review.googlesource.com/18432Reviewed-by: default avatarAustin Clements <austin@google.com>
      Run-TryBot: Russ Cox <rsc@golang.org>
      fac8202c
    • Russ Cox's avatar
      math/big: fix Exp(x, x, x) for certain large x · 1e066cad
      Russ Cox authored
      Fixes #13907.
      
      Change-Id: Ieaa5183f399b12a9177372212adf481c8f0b4a0d
      Reviewed-on: https://go-review.googlesource.com/18491Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      Reviewed-by: default avatarVlad Krasnov <vlad@cloudflare.com>
      Reviewed-by: default avatarAdam Langley <agl@golang.org>
      1e066cad
  2. 12 Jan, 2016 6 commits
  3. 11 Jan, 2016 8 commits
  4. 10 Jan, 2016 5 commits
  5. 09 Jan, 2016 5 commits
  6. 08 Jan, 2016 12 commits