1. 16 Oct, 2016 2 commits
  2. 15 Oct, 2016 8 commits
    • Austin Clements's avatar
      test: simplify fixedbugs/issue15747.go · ad5fd287
      Austin Clements authored
      The error check patterns in this test are more complex than necessary
      because f2 gets inlined into f1. This behavior isn't important to the
      test, so disable inlining of f2 and simplify the error check patterns.
      
      Change-Id: Ia8aee92a52f9217ad71b89b2931494047e8d2185
      Reviewed-on: https://go-review.googlesource.com/31132
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      ad5fd287
    • Austin Clements's avatar
      runtime: use more go:nowritebarrierrec in proc.go · 9897e408
      Austin Clements authored
      Currently we use go:nowritebarrier in many places in proc.go.
      go:notinheap and go:yeswritebarrierrec now let us use
      go:nowritebarrierrec (the recursive form of the go:nowritebarrier
      pragma) more liberally. Do so in proc.go
      
      Change-Id: Ia7fcbc12ce6c51cb24730bf835fb7634ad53462f
      Reviewed-on: https://go-review.googlesource.com/30942Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      9897e408
    • Austin Clements's avatar
      runtime: mark several types go:notinheap · 1bc6be64
      Austin Clements authored
      This covers basically all sysAlloc'd, persistentalloc'd, and
      fixalloc'd types.
      
      Change-Id: I0487c887c2a0ade5e33d4c4c12d837e97468e66b
      Reviewed-on: https://go-review.googlesource.com/30941Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      1bc6be64
    • Austin Clements's avatar
      runtime: make mSpanList more go:notinheap-friendly · 991a85c8
      Austin Clements authored
      Currently mspan links to its previous mspan using a **mspan field that
      points to the previous span's next field. This simplifies some of the
      list manipulation code, but is going to make it very hard to convince
      the compiler that mspan list manipulations don't need write barriers.
      
      Fix this by using a more traditional ("boring") linked list that uses
      a simple *mspan pointer to the previous mspan. This complicates some
      of the list manipulation slightly, but it will let us eliminate all
      write barriers from the mspan list manipulation code by marking mspan
      go:notinheap.
      
      Change-Id: I0d0b212db5f20002435d2a0ed2efc8aa0364b905
      Reviewed-on: https://go-review.googlesource.com/30940Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      991a85c8
    • 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: default avatarKeith Randall <khr@golang.org>
      Reviewed-by: default 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: default avatarMatthew Dempsky <mdempsky@google.com>
      Reviewed-by: default 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: default 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: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      86b2f296
  3. 14 Oct, 2016 3 commits
  4. 13 Oct, 2016 23 commits
  5. 12 Oct, 2016 4 commits
    • Russ Cox's avatar
      syscall: update darwin/amd64 for timespec change · 90a75085
      Russ Cox authored
      Change-Id: I74f47f519dfee10cd079ad9a4e09e36e8d74c6dc
      Reviewed-on: https://go-review.googlesource.com/30937
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      90a75085
    • Joe Tsai's avatar
      archive/tar: reduce allocations in formatOctal · 14e545b6
      Joe Tsai authored
      Change-Id: I9ddb7d2a97d28aba7a107b65f278993daf7807fa
      Reviewed-on: https://go-review.googlesource.com/30960Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      14e545b6
    • Lynn Boger's avatar
      cmd/asm: recognize CR1-CR7 on ppc64x branch instructions · 6da8bdd2
      Lynn Boger authored
      Some of the branch instructions (BEQ, BNE, BLT, etc.) accept
      all the valid CR values as operands, but the CR register value is
      not parsed and not put into the instruction, so that CR0 is always
      used regardless of what was specified on the instruction.  For example
      BEQ CR2,label becomes beq cr0,label.
      
      This adds the change to the PPC64 assembler to recognize the CR value
      and set the approppriate field in the instruction so the correct
      CR is used.  This also adds some general comments on the branch
      instruction BC and its operand values.
      
      Fixes #17408
      
      Change-Id: I8e956372a42846a4c09a7259e9172eaa29118e71
      Reviewed-on: https://go-review.googlesource.com/30930
      Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarDavid Chase <drchase@google.com>
      6da8bdd2
    • Keith Randall's avatar
      cmd/compile,runtime: redo how map assignments work · 442de98c
      Keith Randall authored
      To compile:
        m[k] = v
      instead of:
        mapassign(maptype, m, &k, &v), do
      do:
        *mapassign(maptype, m, &k) = v
      
      mapassign returns a pointer to the value slot in the map.  It is just
      like mapaccess except that it will allocate a new slot if k is not
      already present in the map.
      
      This makes map accesses faster but potentially larger (codewise).
      
      It is faster because the write into the map is done when the compiler
      knows the concrete type, so it can be done with a few store
      instructions instead of calling typedmemmove.  We also potentially
      avoid stack temporaries to hold v.
      
      The code can be larger when the map has pointers in its value type,
      since there is a write barrier call in addition to the mapassign call.
      That makes the code at the callsite a bit bigger (go binary is 0.3%
      bigger).
      
      This CL is in preparation for doing operations like m[k] += v with
      only a single runtime call.  That will roughly double the speed of
      such operations.
      
      Update #17133
      Update #5147
      
      Change-Id: Ia435f032090a2ed905dac9234e693972fe8c2dc5
      Reviewed-on: https://go-review.googlesource.com/30815
      Run-TryBot: Keith Randall <khr@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      442de98c