1. 15 Oct, 2016 4 commits
    • Austin Clements's avatar
      cmd/compile: add go:notinheap type pragma · 77527a31
      Austin Clements authored
      This adds a //go:notinheap pragma for declarations of types that must
      not be heap allocated. We ensure these rules by disallowing new(T),
      make([]T), append([]T), or implicit allocation of T, by disallowing
      conversions to notinheap types, and by propagating notinheap to any
      struct or array that contains notinheap elements.
      
      The utility of this pragma is that we can eliminate write barriers for
      writes to pointers to go:notinheap types, since the write barrier is
      guaranteed to be a no-op. This will let us mark several scheduler and
      memory allocator structures as go:notinheap, which will let us
      disallow write barriers in the scheduler and memory allocator much
      more thoroughly and also eliminate some problematic hybrid write
      barriers.
      
      This also makes go:nowritebarrierrec and go:yeswritebarrierrec much
      more powerful. Currently we use go:nowritebarrier all over the place,
      but it's almost never what you actually want: when write barriers are
      illegal, they're typically illegal for a whole dynamic scope. Partly
      this is because go:nowritebarrier has been around longer, but it's
      also because go:nowritebarrierrec couldn't be used in situations that
      had no-op write barriers or where some nested scope did allow write
      barriers. go:notinheap eliminates many no-op write barriers and
      go:yeswritebarrierrec makes it possible to opt back in to write
      barriers, so these two changes will let us use go:nowritebarrierrec
      far more liberally.
      
      This updates #13386, which is about controlling pointers from non-GC'd
      memory to GC'd memory. That would require some additional pragma (or
      pragmas), but could build on this pragma.
      
      Change-Id: I6314f8f4181535dd166887c9ec239977b54940bd
      Reviewed-on: https://go-review.googlesource.com/30939Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      Reviewed-by: 's avatarMatthew Dempsky <mdempsky@google.com>
      77527a31
    • Austin Clements's avatar
      cmd/compile, runtime: add go:yeswritebarrierrec pragma · a9e6cebd
      Austin Clements authored
      This pragma cancels the effect of go:nowritebarrierrec. This is useful
      in the scheduler because there are places where we enter a function
      without a valid P (and hence cannot have write barriers), but then
      obtain a P. This allows us to annotate the function with
      go:nowritebarrierrec and split out the part after we've obtained a P
      into a go:yeswritebarrierrec function.
      
      Change-Id: Ic8ce4b6d3c074a1ecd8280ad90eaf39f0ffbcc2a
      Reviewed-on: https://go-review.googlesource.com/30938Reviewed-by: 's avatarMatthew Dempsky <mdempsky@google.com>
      Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      a9e6cebd
    • Ilya Tocar's avatar
      strings: use Index in Count · 6347367b
      Ilya Tocar authored
      This simplifies code and provides performance iprovments:
      Similar to https://go-review.googlesource.com/#/c/28577
      
      CountHard1-48               1.74ms ±14%  0.17ms ±14%  -90.16%  (p=0.000 n=19+19)
      CountHard2-48               1.78ms ±15%  0.25ms ±13%  -86.10%  (p=0.000 n=19+20)
      CountHard3-48               1.78ms ±12%  0.80ms ±11%  -55.19%  (p=0.000 n=17+20)
      CountTorture-48             13.5µs ±14%  13.6µs ±11%     ~     (p=0.625 n=18+19)
      CountTortureOverlapping-48  6.92ms ±13%  8.42ms ±11%  +21.72%  (p=0.000 n=19+17)
      
      Change-Id: Ief120aee918a66487c76be56e0796871c8502f89
      Reviewed-on: https://go-review.googlesource.com/28586
      Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      6347367b
    • Daniel Theophanes's avatar
      database/sql: add support for multiple result sets · 86b2f296
      Daniel Theophanes authored
      Many database systems allow returning multiple result sets
      in a single query. This can be useful when dealing with many
      intermediate results on the server and there is a need
      to return more then one arity of data to the client.
      
      Fixes #12382
      
      Change-Id: I480a9ac6dadfc8743e0ba8b6d868ccf8442a9ca1
      Reviewed-on: https://go-review.googlesource.com/30592Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      86b2f296
  2. 14 Oct, 2016 3 commits
  3. 13 Oct, 2016 23 commits
  4. 12 Oct, 2016 10 commits