1. 19 Mar, 2019 23 commits
  2. 18 Mar, 2019 13 commits
    • Keith Randall's avatar
      cmd/compile: better write barrier removal when initializing new objects · ca36af21
      Keith Randall authored
      When initializing a new object, we're often writing
      1) to a location that doesn't have a pointer to a heap object
      2) a pointer that doesn't point to a heap object
      
      When both those conditions are true, we can avoid the write barrier.
      
      This CL detects case 1 by looking for writes to known-zeroed
      locations.  The results of runtime.newobject are zeroed, and we
      perform a simple tracking of which parts of that object are written so
      we can determine what part remains zero at each write.
      
      This CL detects case 2 by looking for addresses of globals (including
      the types and itabs which are used in interfaces) and for nil pointers.
      
      Makes cmd/go 0.3% smaller. Some particular cases, like the slice
      literal in #29573, can get much smaller.
      
      TODO: we can remove actual zero writes also with this mechanism.
      
      Update #29573
      
      Change-Id: Ie74a3533775ea88da0495ba02458391e5db26cb9
      Reviewed-on: https://go-review.googlesource.com/c/go/+/156363
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      ca36af21
    • Philipp Stephani's avatar
      cmd/cgo: use C exact-width integer types to represent Go types · 08751259
      Philipp Stephani authored
      The exact-width integer types are required to use two’s complement
      representation and may not have padding bits, cf. §7.20.1.1/1 in the C11
      standard or https://en.cppreference.com/w/c/types/integer.  This ensures that
      they have the same domain and representation as the corresponding Go types.
      
      Fixes #29878
      
      Change-Id: Ie8a51e91666dfd89731c7859abe47356c94ca1be
      GitHub-Last-Rev: 546a2cc3f1e22dc282757f73c01c91b00899d911
      GitHub-Pull-Request: golang/go#29907
      Reviewed-on: https://go-review.googlesource.com/c/go/+/159258
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      08751259
    • Keith Randall's avatar
      cmd/compile: rename init function from init.ializers back to init · 7b916243
      Keith Randall authored
      The name change init -> init.ializers was initially required for
      initialization code.
      
      With CL 161337 there's no wrapper code any more, there's a data
      structure instead (named .inittask). So we can go back to just
      plain init appearing in tracebacks.
      
      RELNOTE=yes
      
      Update #29919. Followon to CL 161337.
      
      Change-Id: I5a4a49d286df24b53b2baa193dfda482f3ea82a5
      Reviewed-on: https://go-review.googlesource.com/c/go/+/167780
      Run-TryBot: Keith Randall <khr@golang.org>
      Reviewed-by: default avatarJosh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      7b916243
    • bakape's avatar
      net/http: Detect MIME type of v5 RAR archives · 27e444d5
      bakape authored
      Change-Id: Id9dedc861523e2dafe0e67f70862973124fa07b3
      GitHub-Last-Rev: b662561f1980dff9861dd8a738c75a03baa72681
      GitHub-Pull-Request: golang/go#30909
      Reviewed-on: https://go-review.googlesource.com/c/go/+/168039Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      27e444d5
    • Keith Randall's avatar
      runtime: fix registers for bounds check calling convention on arm · 689544c0
      Keith Randall authored
      Some of the registers in which indexes + length were supposed to
      be passed were wrong.
      
      Update #30116
      
      Change-Id: I1089366b7429c1e0ecad9219b847db069ce6b5d6
      Reviewed-on: https://go-review.googlesource.com/c/go/+/168041
      Run-TryBot: Keith Randall <khr@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      689544c0
    • Keith Randall's avatar
      cmd/compile: reorganize init functions · d949d0b9
      Keith Randall authored
      Instead of writing an init function per package that does the same
      thing for every package, just write that implementation once in the
      runtime. Change the compiler to generate a data structure that encodes
      the required initialization operations.
      
      Reduces cmd/go binary size by 0.3%+.  Most of the init code is gone,
      including all the corresponding stack map info. The .inittask
      structures that replace them are quite a bit smaller.
      
      Most usefully to me, there is no longer an init function in every -S output.
      (There is an .inittask global there, but it's much less distracting.)
      
      After this CL we could change the name of the "init.ializers" function
      back to just "init".
      
      Update #6853
      
      R=go1.13
      
      Change-Id: Iec82b205cc52fe3ade4d36406933c97dbc9c01b1
      Reviewed-on: https://go-review.googlesource.com/c/go/+/161337
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarJosh Bleecher Snyder <josharian@gmail.com>
      d949d0b9
    • Joel Sing's avatar
      cmd/dist: sort gohostos switch entries · 991c85a7
      Joel Sing authored
      Sort gohostos switch entries for readability/maintainability.
      
      Change-Id: I565b0aee33e8463502faa68eaceea6f7dccca66b
      Reviewed-on: https://go-review.googlesource.com/c/go/+/154379
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarTobias Klauser <tobias.klauser@gmail.com>
      991c85a7
    • Matthew Dempsky's avatar
      cmd/compile: fix importing rewritten f(g()) calls · 916e861f
      Matthew Dempsky authored
      golang.org/cl/166983 started serializing the Ninit field of OCALL
      nodes within function inline bodies (necessary to fix a regression in
      building crypto/ecdsa with -gcflags=-l=4), but this means the Ninit
      field needs to be typechecked when the imported function body is used.
      
      It's unclear why this wasn't necessary for the crypto/ecdsa
      regression.
      
      Fixes #30907.
      
      Change-Id: Id5f0bf3c4d17bbd6d5318913b859093c93a0a20c
      Reviewed-on: https://go-review.googlesource.com/c/go/+/168199
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      916e861f
    • Keith Randall's avatar
      cmd/compile,runtime: provide index information on bounds check failure · 2c423f06
      Keith Randall authored
      A few examples (for accessing a slice of length 3):
      
         s[-1]    runtime error: index out of range [-1]
         s[3]     runtime error: index out of range [3] with length 3
         s[-1:0]  runtime error: slice bounds out of range [-1:]
         s[3:0]   runtime error: slice bounds out of range [3:0]
         s[3:-1]  runtime error: slice bounds out of range [:-1]
         s[3:4]   runtime error: slice bounds out of range [:4] with capacity 3
         s[0:3:4] runtime error: slice bounds out of range [::4] with capacity 3
      
      Note that in cases where there are multiple things wrong with the
      indexes (e.g. s[3:-1]), we report one of those errors kind of
      arbitrarily, currently the rightmost one.
      
      An exhaustive set of examples is in issue30116[u].out in the CL.
      
      The message text has the same prefix as the old message text. That
      leads to slightly awkward phrasing but hopefully minimizes the chance
      that code depending on the error text will break.
      
      Increases the size of the go binary by 0.5% (amd64). The panic functions
      take arguments in registers in order to keep the size of the compiled code
      as small as possible.
      
      Fixes #30116
      
      Change-Id: Idb99a827b7888822ca34c240eca87b7e44a04fdd
      Reviewed-on: https://go-review.googlesource.com/c/go/+/161477
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarDavid Chase <drchase@google.com>
      2c423f06
    • Daniel Theophanes's avatar
      cmd/go: allow -o to point to a folder that writes multiple execs · b48bda9c
      Daniel Theophanes authored
      If -o points to a directory that exists then allow multiple
      executables to be written to that directory.
      
      Fixes #14295
      
      Change-Id: Ic951e637c70a2ada5e7534bae9a43901a39fe2c5
      Reviewed-on: https://go-review.googlesource.com/c/go/+/167679
      Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      b48bda9c
    • Martin Möhrmann's avatar
      runtime: replace division by span element size by multiply and shifts · 6ca51f78
      Martin Möhrmann authored
      Divisions are generally slow. The compiler can optimize a division
      to use a sequence of faster multiplies and shifts (magic constants)
      if the divisor is not know at compile time.
      
      The value of the span element size in mcentral.grow is not known at
      compile time but magic constants to compute n / span.elementsize
      are already stored in class_to_divmagic and mspan.
      They however need to be adjusted to work for
      (0 <= n <= span.npages * pagesize) instead of
      (0 <= n <  span.npages * pagesize).
      
      Change-Id: Ieea59f1c94525a88d012f2557d43691967900deb
      Reviewed-on: https://go-review.googlesource.com/c/go/+/148057
      Run-TryBot: Martin Möhrmann <moehrmann@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      6ca51f78
    • Daniel Martí's avatar
      encoding/json: fix performance regression in the decoder · e5f6e2d1
      Daniel Martí authored
      In golang.org/cl/145218, a feature was added where the JSON decoder
      would keep track of the entire path to a field when reporting an
      UnmarshalTypeError.
      
      However, we all failed to check if this affected the benchmarks - myself
      included, as a reviewer. Below are the numbers comparing the CL's parent
      with itself, once it was merged:
      
      name           old time/op    new time/op    delta
      CodeDecoder-8    12.9ms ± 1%    28.2ms ± 2%   +119.33%  (p=0.002 n=6+6)
      
      name           old speed      new speed      delta
      CodeDecoder-8   151MB/s ± 1%    69MB/s ± 3%    -54.40%  (p=0.002 n=6+6)
      
      name           old alloc/op   new alloc/op   delta
      CodeDecoder-8    2.74MB ± 0%  109.39MB ± 0%  +3891.83%  (p=0.002 n=6+6)
      
      name           old allocs/op  new allocs/op  delta
      CodeDecoder-8     77.5k ± 0%    168.5k ± 0%   +117.30%  (p=0.004 n=6+5)
      
      The reason why the decoder got twice as slow is because it now allocated
      ~40x as many objects, which puts a lot of pressure on the garbage
      collector.
      
      The reason is that the CL concatenated strings every time a nested field
      was decoded. In other words, practically every field generated garbage
      when decoded. This is hugely wasteful, especially considering that the
      vast majority of JSON decoding inputs won't return UnmarshalTypeError.
      
      Instead, use a stack of fields, and make sure to always use the same
      backing array, to ensure we only need to grow the slice to the maximum
      depth once.
      
      The original CL also introduced a bug. The field stack string wasn't
      reset to its original state when reaching "d.opcode == scanEndObject",
      so the last field in a decoded struct could leak. For example, an added
      test decodes a list of structs, and encoding/json before this CL would
      fail:
      
      	got:  cannot unmarshal string into Go struct field T.Ts.Y.Y.Y of type int
      	want: cannot unmarshal string into Go struct field T.Ts.Y of type int
      
      To fix that, simply reset the stack after decoding every field, even if
      it's the last.
      
      Below is the original performance versus this CL. There's a tiny
      performance hit, probably due to the append for every decoded field, but
      at least we're back to the usual ~150MB/s.
      
      name           old time/op    new time/op    delta
      CodeDecoder-8    12.9ms ± 1%    13.0ms ± 1%  +1.25%  (p=0.009 n=6+6)
      
      name           old speed      new speed      delta
      CodeDecoder-8   151MB/s ± 1%   149MB/s ± 1%  -1.24%  (p=0.009 n=6+6)
      
      name           old alloc/op   new alloc/op   delta
      CodeDecoder-8    2.74MB ± 0%    2.74MB ± 0%  +0.00%  (p=0.002 n=6+6)
      
      name           old allocs/op  new allocs/op  delta
      CodeDecoder-8     77.5k ± 0%     77.5k ± 0%  +0.00%  (p=0.002 n=6+6)
      
      Finally, make all of these benchmarks report allocs by default. The
      decoder ones are pretty sensitive to generated garbage, so ReportAllocs
      would have made the performance regression more obvious.
      
      Change-Id: I67b50f86b2e72f55539429450c67bfb1a9464b67
      Reviewed-on: https://go-review.googlesource.com/c/go/+/167978Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      e5f6e2d1
    • Tobias Klauser's avatar
      internal/bytealg: share code for IndexByte functions on arm · 3496ff1d
      Tobias Klauser authored
      Move the shared code of IndexByte and IndexByteString into
      indexbytebody. This will allow to implement optimizations (e.g.
      for #29001) in a single function.
      
      Change-Id: I1d550da8eb65f95e492a460a12058cc35b1162b6
      Reviewed-on: https://go-review.googlesource.com/c/go/+/167939
      Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      3496ff1d
  3. 17 Mar, 2019 3 commits
    • Elias Naur's avatar
      os: only fallback to root directory if $HOME fails for UserHomeDir · bedb6a18
      Elias Naur authored
      UserHomeDir always returns "/" for platforms where the home directory
      is not always well defined. However, the user might set HOME before
      running a Go program on those platforms and on at least iOS, HOME
      is actually set to something useful (the root of the app specific
      writable directory).
      
      This CL changes UserHomeDir to use the root directory "/" only if
      $HOME is empty.
      
      Change-Id: Icaa01de53cd585d527d9a23b1629375d6b7f67e9
      Reviewed-on: https://go-review.googlesource.com/c/go/+/167802
      Run-TryBot: Elias Naur <mail@eliasnaur.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarTobias Klauser <tobias.klauser@gmail.com>
      bedb6a18
    • Tobias Klauser's avatar
      internal/bytealg: use word-wise comparison for Equal on arm · a734601b
      Tobias Klauser authored
      Follow CL 165338 and use word-wise comparison for aligned buffers in
      Equal on arm, otherwise fall back to the current byte-wise comparison.
      
      name                 old time/op    new time/op    delta
      Equal/0-4              25.7ns ± 1%    23.5ns ± 1%    -8.78%  (p=0.000 n=10+10)
      Equal/1-4              65.8ns ± 0%    60.1ns ± 1%    -8.69%  (p=0.000 n=10+9)
      Equal/6-4              82.9ns ± 1%    86.7ns ± 0%    +4.59%  (p=0.000 n=10+10)
      Equal/9-4              90.0ns ± 0%   101.0ns ± 0%   +12.18%  (p=0.000 n=9+10)
      Equal/15-4              108ns ± 0%     119ns ± 0%   +10.19%  (p=0.000 n=8+8)
      Equal/16-4              111ns ± 0%      82ns ± 0%   -26.37%  (p=0.000 n=8+10)
      Equal/20-4              124ns ± 1%      87ns ± 1%   -29.94%  (p=0.000 n=9+10)
      Equal/32-4              160ns ± 1%      97ns ± 1%   -39.40%  (p=0.000 n=10+10)
      Equal/4K-4             14.0µs ± 0%     3.6µs ± 1%   -74.57%  (p=0.000 n=9+10)
      Equal/4M-4             12.8ms ± 1%     3.2ms ± 0%   -74.93%  (p=0.000 n=9+9)
      Equal/64M-4             204ms ± 1%      51ms ± 0%   -74.78%  (p=0.000 n=10+10)
      EqualPort/1-4          47.0ns ± 1%    46.8ns ± 0%    -0.40%  (p=0.015 n=10+6)
      EqualPort/6-4          82.6ns ± 1%    81.9ns ± 1%    -0.87%  (p=0.002 n=10+10)
      EqualPort/32-4          232ns ± 0%     232ns ± 0%      ~     (p=0.496 n=8+10)
      EqualPort/4K-4         29.0µs ± 1%    29.0µs ± 1%      ~     (p=0.604 n=9+10)
      EqualPort/4M-4         24.0ms ± 1%    23.8ms ± 0%    -0.65%  (p=0.001 n=9+9)
      EqualPort/64M-4         383ms ± 1%     382ms ± 0%      ~     (p=0.218 n=10+10)
      CompareBytesEqual-4    61.2ns ± 1%    61.0ns ± 1%      ~     (p=0.539 n=10+10)
      
      name                 old speed      new speed      delta
      Equal/1-4            15.2MB/s ± 0%  16.6MB/s ± 1%    +9.52%  (p=0.000 n=10+9)
      Equal/6-4            72.4MB/s ± 1%  69.2MB/s ± 0%    -4.40%  (p=0.000 n=10+10)
      Equal/9-4             100MB/s ± 0%    89MB/s ± 0%   -11.40%  (p=0.000 n=9+10)
      Equal/15-4            138MB/s ± 1%   125MB/s ± 1%    -9.41%  (p=0.000 n=10+10)
      Equal/16-4            144MB/s ± 1%   196MB/s ± 0%   +36.41%  (p=0.000 n=10+10)
      Equal/20-4            162MB/s ± 1%   231MB/s ± 1%   +42.98%  (p=0.000 n=9+10)
      Equal/32-4            200MB/s ± 1%   331MB/s ± 1%   +65.64%  (p=0.000 n=10+10)
      Equal/4K-4            292MB/s ± 0%  1149MB/s ± 1%  +293.19%  (p=0.000 n=9+10)
      Equal/4M-4            328MB/s ± 1%  1307MB/s ± 0%  +298.87%  (p=0.000 n=9+9)
      Equal/64M-4           329MB/s ± 1%  1306MB/s ± 0%  +296.56%  (p=0.000 n=10+10)
      EqualPort/1-4        21.3MB/s ± 1%  21.4MB/s ± 0%    +0.42%  (p=0.002 n=10+9)
      EqualPort/6-4        72.6MB/s ± 1%  73.2MB/s ± 1%    +0.87%  (p=0.003 n=10+10)
      EqualPort/32-4        138MB/s ± 0%   138MB/s ± 0%      ~     (p=0.953 n=9+10)
      EqualPort/4K-4        141MB/s ± 1%   141MB/s ± 1%      ~     (p=0.382 n=10+10)
      EqualPort/4M-4        175MB/s ± 1%   176MB/s ± 0%    +0.65%  (p=0.001 n=9+9)
      EqualPort/64M-4       175MB/s ± 1%   176MB/s ± 0%      ~     (p=0.225 n=10+10)
      
      The 5-12% decrease in performance on Equal/{6,9,15} are due to the
      benchmarks splitting the bytes buffer in half. The b argument to Equal
      then ends up being unaligned and thus the fast word-wise compare doesn't
      kick in.
      
      Updates #29001
      
      Change-Id: I73be501c18e67d211ed19da7771b4f254254e609
      Reviewed-on: https://go-review.googlesource.com/c/go/+/167557
      Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      a734601b
    • Elias Naur's avatar
      cmd/go,misc/ios: fix tests on iOS · 746f405f
      Elias Naur authored
      Now that modules are always on, cmd/go tests require a valid
      GOCACHE. However, on iOS where the go tool is not available, the
      cmd/go test driver ends up setting GOCACHE to the empty string.
      Fix it by falling back to the builtin default cache directory.
      
      The iOS exec wrapper passes the environment variables to the app
      on the device, including $HOME used for the default cache directory.
      Skip $HOME to let the device specific and writable $HOME be used
      instead.
      
      Should fix cmd/go on the iOS builders that broke when GO111MODULE
      defaulted to on.
      
      Change-Id: I0939f5b8aaa1d2db95e64c99f4130eee2d0b4d4d
      Reviewed-on: https://go-review.googlesource.com/c/go/+/167938
      Run-TryBot: Elias Naur <mail@eliasnaur.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      746f405f
  4. 16 Mar, 2019 1 commit