1. 03 Mar, 2017 14 commits
    • David Lazar's avatar
      cmd/compile: copy literals when inlining · 1c6ef9ae
      David Lazar authored
      Without this, literals keep their original source positions through
      inlining, which results in strange jumps in line numbers of inlined
      function bodies. By copying literals, inlining can update their source
      position like other nodes.
      
      Fixes #15453.
      
      Change-Id: Iad5d9bbfe183883794213266dc30e31bab89ee69
      Reviewed-on: https://go-review.googlesource.com/37232
      Run-TryBot: David Lazar <lazard@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      1c6ef9ae
    • David Lazar's avatar
      cmd/compile,link: generate PC-value tables with inlining information · 699175a1
      David Lazar authored
      In order to generate accurate tracebacks, the runtime needs to know the
      inlined call stack for a given PC. This creates two tables per function
      for this purpose. The first table is the inlining tree (stored in the
      function's funcdata), which has a node containing the file, line, and
      function name for every inlined call. The second table is a PC-value
      table that maps each PC to a node in the inlining tree (or -1 if the PC
      is not the result of inlining).
      
      To give the appearance that inlining hasn't happened, the runtime also
      needs the original source position information of inlined AST nodes.
      Previously the compiler plastered over the line numbers of inlined AST
      nodes with the line number of the call. This meant that the PC-line
      table mapped each PC to line number of the outermost call in its inlined
      call stack, with no way to access the innermost line number.
      
      Now the compiler retains line numbers of inlined AST nodes and writes
      the innermost source position information to the PC-line and PC-file
      tables. Some tools and tests expect to see outermost line numbers, so we
      provide the OutermostLine function for displaying line info.
      
      To keep track of the inlined call stack for an AST node, we extend the
      src.PosBase type with an index into a global inlining tree. Every time
      the compiler inlines a call, it creates a node in the global inlining
      tree for the call, and writes its index to the PosBase of every inlined
      AST node. The parent of this node is the inlining tree index of the
      call. -1 signifies no parent.
      
      For each function, the compiler creates a local inlining tree and a
      PC-value table mapping each PC to an index in the local tree.  These are
      written to an object file, which is read by the linker.  The linker
      re-encodes these tables compactly by deduplicating function names and
      file names.
      
      This change increases the size of binaries by 4-5%. For example, this is
      how the go1 benchmark binary is impacted by this change:
      
      section             old bytes   new bytes   delta
      .text               3.49M ± 0%  3.49M ± 0%   +0.06%
      .rodata             1.12M ± 0%  1.21M ± 0%   +8.21%
      .gopclntab          1.50M ± 0%  1.68M ± 0%  +11.89%
      .debug_line          338k ± 0%   435k ± 0%  +28.78%
      Total               9.21M ± 0%  9.58M ± 0%   +4.01%
      
      Updates #19348.
      
      Change-Id: Ic4f180c3b516018138236b0c35e0218270d957d3
      Reviewed-on: https://go-review.googlesource.com/37231
      Run-TryBot: David Lazar <lazard@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      699175a1
    • Aliaksandr Valialkin's avatar
      cmd/compile: pack bool fields in Node, Name, Func and Type structs to bitsets · ed70f37e
      Aliaksandr Valialkin authored
      This reduces compiler memory usage by up to 4% - see compilebench
      results below.
      
      name       old time/op     new time/op     delta
      Template       245ms ± 4%      241ms ± 2%  -1.88%  (p=0.029 n=10+10)
      Unicode        126ms ± 3%      124ms ± 3%    ~     (p=0.105 n=10+10)
      GoTypes        805ms ± 2%      813ms ± 3%    ~     (p=0.515 n=8+10)
      Compiler       3.95s ± 2%      3.83s ± 1%  -2.96%  (p=0.000 n=9+10)
      MakeBash       47.4s ± 4%      46.6s ± 1%  -1.59%  (p=0.028 n=9+10)
      
      name       old user-ns/op  new user-ns/op  delta
      Template        324M ± 5%       326M ± 3%    ~     (p=0.935 n=10+10)
      Unicode         186M ± 5%       178M ±10%    ~     (p=0.067 n=9+10)
      GoTypes        1.08G ± 7%      1.09G ± 4%    ~     (p=0.956 n=10+10)
      Compiler       5.34G ± 4%      5.31G ± 1%    ~     (p=0.501 n=10+8)
      
      name       old alloc/op    new alloc/op    delta
      Template      41.0MB ± 0%     39.8MB ± 0%  -3.03%  (p=0.000 n=10+10)
      Unicode       32.3MB ± 0%     31.0MB ± 0%  -4.13%  (p=0.000 n=10+10)
      GoTypes        119MB ± 0%      116MB ± 0%  -2.39%  (p=0.000 n=10+10)
      Compiler       499MB ± 0%      487MB ± 0%  -2.48%  (p=0.000 n=10+10)
      
      name       old allocs/op   new allocs/op   delta
      Template        380k ± 1%       379k ± 1%    ~     (p=0.436 n=10+10)
      Unicode         324k ± 1%       324k ± 0%    ~     (p=0.853 n=10+10)
      GoTypes        1.15M ± 0%      1.15M ± 0%    ~     (p=0.481 n=10+10)
      Compiler       4.41M ± 0%      4.41M ± 0%  -0.12%  (p=0.007 n=10+10)
      
      name       old text-bytes  new text-bytes  delta
      HelloSize       623k ± 0%       623k ± 0%    ~     (all equal)
      CmdGoSize      6.64M ± 0%      6.64M ± 0%    ~     (all equal)
      
      name       old data-bytes  new data-bytes  delta
      HelloSize      5.81k ± 0%      5.81k ± 0%    ~     (all equal)
      CmdGoSize       238k ± 0%       238k ± 0%    ~     (all equal)
      
      name       old bss-bytes   new bss-bytes   delta
      HelloSize       134k ± 0%       134k ± 0%    ~     (all equal)
      CmdGoSize       152k ± 0%       152k ± 0%    ~     (all equal)
      
      name       old exe-bytes   new exe-bytes   delta
      HelloSize       967k ± 0%       967k ± 0%    ~     (all equal)
      CmdGoSize      10.2M ± 0%      10.2M ± 0%    ~     (all equal)
      
      Change-Id: I1f40af738254892bd6c8ba2eb43390b175753d52
      Reviewed-on: https://go-review.googlesource.com/37445Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      ed70f37e
    • Johan Brandhorst's avatar
      net/http/httptest: add Client and Certificate methods to Server · fbf4dd91
      Johan Brandhorst authored
      Adds a function for easily accessing the x509.Certificate
      of a Server, if there is one. Also adds a helper function
      for getting a http.Client suitable for use with the server.
      
      This makes the steps required to test a httptest
      TLS server simpler.
      
      Fixes #18411
      
      Change-Id: I2e78fe1e54e31bed9c641be2d9a099f698c7bbde
      Reviewed-on: https://go-review.googlesource.com/34639Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      fbf4dd91
    • Matthew Dempsky's avatar
      cmd/compile/internal/ssa: remove Hmul{8,16}{,u} ops · 02e36f8c
      Matthew Dempsky authored
      Change-Id: I90865921584ae4bdfb6c220d439b14593d72b6f9
      Reviewed-on: https://go-review.googlesource.com/37752
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      02e36f8c
    • Cherry Zhang's avatar
      cmd/compile: remove zeroing after newobject · c8eaeb8c
      Cherry Zhang authored
      The Zero op right after newobject has been removed. But this rule
      does not cover Store of constant zero (for SSA-able types). Add
      rules to cover Store op as well.
      
      Updates #19027.
      
      Change-Id: I5d2b62eeca0aa9ce8dc7205b264b779de01c660b
      Reviewed-on: https://go-review.googlesource.com/36836
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      c8eaeb8c
    • Cherry Zhang's avatar
      cmd/compile: fix optimization of Zero newobject on amd64p32 · 9b480521
      Cherry Zhang authored
      On amd64p32, PtrSize and RegSize don't agree, and function return
      value is aligned with RegSize. Fix this rule. Other architectures
      are not affected, where PtrSize and RegSize are the same.
      
      Change-Id: If187d3dfde3dc3b931b8e97db5eeff49a781551b
      Reviewed-on: https://go-review.googlesource.com/37720
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      9b480521
    • Matthew Dempsky's avatar
      cmd/compile/internal/gc: remove OHMUL Op · d8a0f748
      Matthew Dempsky authored
      Previously the compiler rewrote constant division into OHMUL
      operations, but that rewriting was moved to SSA in CL 37015. Now OHMUL
      is unused, so we can get rid of it.
      
      Change-Id: Ib6fc7c2b6435510bafb5735b3b4f42cfd8ed8cdb
      Reviewed-on: https://go-review.googlesource.com/37750
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      d8a0f748
    • Austin Clements's avatar
      runtime: clarify access to mheap_.busy · 77f64c50
      Austin Clements authored
      There are two accesses to mheap_.busy that are guarded by checks
      against len(mheap_.free). This works because both lists are (and must
      be) the same length, but it makes the code less clear. Change these to
      use len(mheap_.busy) so the access more clearly parallels the check.
      
      Fixes #18944.
      
      Change-Id: I9bacbd3663988df351ed4396ae9018bc71018311
      Reviewed-on: https://go-review.googlesource.com/36354
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      77f64c50
    • Austin Clements's avatar
      runtime: simplify sweep allocation counting · b50b7285
      Austin Clements authored
      Currently sweep counts the number of allocated objects, computes the
      number of free objects from that, then re-computes the number of
      allocated objects from that. Simplify and clean this up by skipping
      these intermediate steps.
      
      Change-Id: I3ed98e371eb54bbcab7c8530466c4ab5fde35f0a
      Reviewed-on: https://go-review.googlesource.com/34935
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMarvin Stenger <marvin.stenger94@gmail.com>
      Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      b50b7285
    • Austin Clements's avatar
      runtime: don't rescan finalizers queue during mark termination · f1ba75f8
      Austin Clements authored
      Currently we scan the finalizers queue both during concurrent mark and
      during mark termination. This costs roughly 20ns per queued finalizer
      and about 1ns per unused finalizer queue slot (allocated queue length
      never decreases), which can drive up STW time if there are many
      finalizers.
      
      However, we only add finalizers to this queue during sweeping, which
      means that the second scan will never find anything new. Hence, we can
      fix this by simply not scanning the finalizers queue during mark
      termination. This brings the STW time under the 100µs goal even with
      1,000,000 queued finalizers.
      
      Fixes #18869.
      
      Change-Id: I4ce5620c66fb7f13ebeb39ca313ce57047d1d0fb
      Reviewed-on: https://go-review.googlesource.com/36013
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      f1ba75f8
    • Austin Clements's avatar
      runtime: remove wbufptr · 98da2d1f
      Austin Clements authored
      Since workbuf is now marked go:notinheap, the write barrier-preventing
      wrapper type wbufptr is no longer necessary. Remove it.
      
      Change-Id: I3e5b5803a1547d65de1c1a9c22458a38e08549b7
      Reviewed-on: https://go-review.googlesource.com/35971
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      98da2d1f
    • Austin Clements's avatar
      cmd/compile: accept string debug flags · 8eb14e9d
      Austin Clements authored
      The compiler's -d flag accepts string-valued flags, but currently only
      for SSA debug flags. Extend it to support string values for other
      flags. This also makes the syntax somewhat more sane so flag=value and
      flag:value now both accept integers and strings.
      
      Change-Id: Idd144d8479a430970cc1688f824bffe0a56ed2df
      Reviewed-on: https://go-review.googlesource.com/37345
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarDavid Chase <drchase@google.com>
      8eb14e9d
    • Cherry Zhang's avatar
      cmd/compile: get rid of "volatile" in SSA · 5bfd1ef0
      Cherry Zhang authored
      A value is "volatile" if it is a pointer to the argument region
      on stack which will be clobbered by function call. This is used
      to make sure the value is safe when inserting write barrier calls.
      The writebarrier pass can tell whether a value is such a pointer.
      Therefore no need to mark it when building SSA and thread this
      information through.
      
      Passes "toolstash -cmp" on std.
      
      Updates #17583.
      
      Change-Id: Idc5fc0d710152b94b3c504ce8db55ea9ff5b5195
      Reviewed-on: https://go-review.googlesource.com/36835
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      5bfd1ef0
  2. 02 Mar, 2017 26 commits