1. 11 Nov, 2019 8 commits
    • Than McIntosh's avatar
      cmd/go: address DWARF linker issues with -buildmode=plugin on Darwin · 795e8c23
      Than McIntosh authored
      Assorted fixups in the linker needed to enable turning back on
      DWARF generation when building plugins for Darwin. Includes:
      
       - don't suppress import of runtime/cgo in the linker for
         Darwin if we are linking in plugin mode
      
       - in calcCompUnitRanges handle the case where we encounter
         linker-generated functions that have no associated Unit (and
         also have no DWARF)
      
       - generalize a guard in relocsym() include so as to avoid
         triggering a spurious error on go.info symbols in plugin mode
      
      Updates #21647.
      Updates #27502.
      
      Change-Id: I317fea97bef2f3461e31498e63f9fd6d8b8f4b23
      Reviewed-on: https://go-review.googlesource.com/c/go/+/182959
      Run-TryBot: Than McIntosh <thanm@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      Reviewed-by: default avatarEmmanuel Odeke <emm.odeke@gmail.com>
      795e8c23
    • Daniel Martí's avatar
      encoding/json: error when encoding a pointer cycle · 64c9ee98
      Daniel Martí authored
      Otherwise we'd panic with a stack overflow.
      
      Most programs are in control of the data being encoded and can ensure
      there are no cycles, but sometimes it's not that simple. For example,
      running a user's html template with script tags can easily result in
      crashes if the user can find a pointer cycle.
      
      Adding the checks via a map to every ptrEncoder.encode call slowed down
      the benchmarks below by a noticeable 13%. Instead, only start doing the
      relatively expensive pointer cycle checks if we're many levels of
      pointers deep in an encode state.
      
      A threshold of 1000 is small enough to capture pointer cycles before
      they're a problem (the goroutine stack limit is currently 1GB, and I
      needed close to a million levels to reach it). Yet it's large enough
      that reasonable uses of the json encoder only see a tiny 1% slow-down
      due to the added ptrLevel field and check.
      
      	name           old time/op    new time/op    delta
      	CodeEncoder-8    2.34ms ± 1%    2.37ms ± 0%  +1.05%  (p=0.000 n=10+10)
      	CodeMarshal-8    2.42ms ± 1%    2.44ms ± 0%  +1.10%  (p=0.000 n=10+10)
      
      	name           old speed      new speed      delta
      	CodeEncoder-8   829MB/s ± 1%   820MB/s ± 0%  -1.04%  (p=0.000 n=10+10)
      	CodeMarshal-8   803MB/s ± 1%   795MB/s ± 0%  -1.09%  (p=0.000 n=10+10)
      
      	name           old alloc/op   new alloc/op   delta
      	CodeEncoder-8    43.1kB ± 8%    42.5kB ±10%    ~     (p=0.989 n=10+10)
      	CodeMarshal-8    1.99MB ± 0%    1.99MB ± 0%    ~     (p=0.254 n=9+6)
      
      	name           old allocs/op  new allocs/op  delta
      	CodeEncoder-8      0.00           0.00         ~     (all equal)
      	CodeMarshal-8      1.00 ± 0%      1.00 ± 0%    ~     (all equal)
      
      Finally, add a few tests to ensure that the code handles the edge cases
      properly.
      
      Fixes #10769.
      
      Change-Id: I73d48e0cf6ea140127ea031f2dbae6e6a55e58b8
      Reviewed-on: https://go-review.googlesource.com/c/go/+/187920
      Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBjørn Erik Pedersen <bjorn.erik.pedersen@gmail.com>
      Reviewed-by: default avatarAndrew Bonventre <andybons@golang.org>
      64c9ee98
    • Michael Anthony Knyszek's avatar
      runtime: fix min/max logic in findScavengeCandidate · f5114675
      Michael Anthony Knyszek authored
      Before this CL, if max > min and max was unaligned to min, then the
      function could return an unaligned (unaligned to min) region to
      scavenge. On most platforms, this leads to some kind of crash.
      
      Fix this by explicitly aligning max to the next multiple of min.
      
      Fixes #35445.
      Updates #35112.
      
      Change-Id: I0af42d4a307b48a97e47ed152c619d77b0298291
      Reviewed-on: https://go-review.googlesource.com/c/go/+/206277Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      f5114675
    • Constantin Konstantinidis's avatar
      cmd/go: error out of 'go mod download' if the main module is passed as argument · 696c4148
      Constantin Konstantinidis authored
      Test added.
      
      Fixes #28338
      
      Change-Id: Iab72ba5646360ae91671261161d8fda451f7a717
      Reviewed-on: https://go-review.googlesource.com/c/go/+/189797
      Run-TryBot: Bryan C. Mills <bcmills@google.com>
      Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      696c4148
    • Michael Munday's avatar
      cmd/compile, runtime: intrinsify atomic And8 and Or8 on s390x · b3885dbc
      Michael Munday authored
      Intrinsify these functions to match other platforms. Update the
      sequence of instructions used in the assembly implementations to
      match the intrinsics.
      
      Also, add a micro benchmark so we can more easily measure the
      performance of these two functions:
      
      name            old time/op  new time/op  delta
      And8-8          5.33ns ± 7%  2.55ns ± 8%  -52.12%  (p=0.000 n=20+20)
      And8Parallel-8  7.39ns ± 5%  3.74ns ± 4%  -49.34%  (p=0.000 n=20+20)
      Or8-8           4.84ns ±15%  2.64ns ±11%  -45.50%  (p=0.000 n=20+20)
      Or8Parallel-8   7.27ns ± 3%  3.84ns ± 4%  -47.10%  (p=0.000 n=19+20)
      
      By using a 'rotate then xor selected bits' instruction combined with
      either a 'load and and' or a 'load and or' instruction we can
      implement And8 and Or8 with far fewer instructions. Replacing
      'compare and swap' with atomic instructions may also improve
      performance when there is contention.
      
      Change-Id: I28bb8032052b73ae8ccdf6e4c612d2877085fa01
      Reviewed-on: https://go-review.googlesource.com/c/go/+/204277
      Run-TryBot: Michael Munday <mike.munday@ibm.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      b3885dbc
    • Cherry Zhang's avatar
      runtime: don't save G during VDSO if we're handling signal · 75c839af
      Cherry Zhang authored
      On some platforms (currently ARM and ARM64), when calling into
      VDSO we store the G to the gsignal stack, if there is one, so if
      we receive a signal during VDSO we can find the G.
      
      If we receive a signal during VDSO, and within the signal handler
      we call nanotime again (e.g. when handling profiling signal),
      we'll save/clear the G slot on the gsignal stack again, which
      clobbers the original saved G. If we receive a second signal
      during the same VDSO execution, we will fetch a nil G, which will
      lead to bad things such as deadlock.
      
      Don't save G if we're calling VDSO code from the gsignal stack.
      Saving G is not necessary as we won't receive a nested signal.
      
      Fixes #35473.
      
      Change-Id: Ibfd8587a3c70c2f1533908b056e81b94d75d65a5
      Reviewed-on: https://go-review.googlesource.com/c/go/+/206397
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      75c839af
    • Bryan C. Mills's avatar
      runtime/pprof: skip checks for inlined functions when inlining is disabled · c31bcd13
      Bryan C. Mills authored
      Fixes #35463
      
      Change-Id: I29af27b77cc651395c20570943847729ff12586c
      Reviewed-on: https://go-review.googlesource.com/c/go/+/206297
      Run-TryBot: Bryan C. Mills <bcmills@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      c31bcd13
    • DQNEO's avatar
      cmd/compile: rename sizeof_Array and array_* to slice_* · f07059d9
      DQNEO authored
      Renames variables sizeof_Array and other array_* variables
      that were actually intended for slices and not arrays.
      
      Change-Id: I391b95880cc77cabb8472efe694b7dd19545f31a
      Reviewed-on: https://go-review.googlesource.com/c/go/+/180919Reviewed-by: default avatarEmmanuel Odeke <emm.odeke@gmail.com>
      Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      f07059d9
  2. 10 Nov, 2019 8 commits
  3. 09 Nov, 2019 6 commits
  4. 08 Nov, 2019 18 commits