1. 12 Dec, 2019 1 commit
  2. 11 Dec, 2019 8 commits
    • Bryan C. Mills's avatar
      cmd/go: allow arguments to 'go test' and 'go vet' to duplicate or override flags from GOFLAGS · a15b5d30
      Bryan C. Mills authored
      This is a minimal fix for Go 1.14, but this parsing logic is much too
      complex and seems like it will cause more trouble going forward.
      
      I intend to mail a followup change to refactor this logic for 1.15.
      
      Updates #32471
      
      Change-Id: I00ed07dcf3a23c9cd4ffa8cf764921fb5c18bcd6
      Reviewed-on: https://go-review.googlesource.com/c/go/+/210940
      Run-TryBot: Bryan C. Mills <bcmills@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      a15b5d30
    • Michael Anthony Knyszek's avatar
      runtime: use inUse ranges to map in summary memory only as needed · 1b1fbb31
      Michael Anthony Knyszek authored
      Prior to this change, if the heap was very discontiguous (such as in
      TestArenaCollision) it's possible we could map a large amount of memory
      as R/W and commit it. We would use only the start and end to track what
      should be mapped, and we would extend that mapping as needed to
      accomodate a potentially fragmented address space.
      
      After this change, we only map exactly the part of the summary arrays
      that we need by using the inUse ranges from the previous change. This
      reduces the GCSys footprint of TestArenaCollision from 300 MiB to 18
      MiB.
      
      Because summaries are no longer mapped contiguously, this means the
      scavenger can no longer iterate directly. This change also updates the
      scavenger to borrow ranges out of inUse and iterate over only the
      parts of the heap which are actually currently in use. This is both an
      optimization and necessary for correctness.
      
      Fixes #35514.
      
      Change-Id: I96bf0c73ed0d2d89a00202ece7b9d089a53bac90
      Reviewed-on: https://go-review.googlesource.com/c/go/+/207758
      Run-TryBot: Michael Knyszek <mknyszek@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      1b1fbb31
    • Cherry Zhang's avatar
      test: add a test for gccgo compiler bug of missing type descriptor · 6f2b8347
      Cherry Zhang authored
      The gccgo compiler did not generate type descriptor for a pointer
      to a type alias defined in another package, causing linking error.
      The fix is CL 210787. This CL adds a test.
      
      Updates #36085.
      
      Change-Id: I3237c7fedb4d92fb2dc610ee2b88087f96dc2a1a
      Reviewed-on: https://go-review.googlesource.com/c/go/+/210858
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      6f2b8347
    • Michael Anthony Knyszek's avatar
      runtime: track ranges of address space which are owned by the heap · 9d78e75a
      Michael Anthony Knyszek authored
      This change adds a new inUse field to the allocator which tracks ranges
      of addresses that are owned by the heap. It is updated on each heap
      growth.
      
      These ranges are tracked in an array which is kept sorted. In practice
      this array shouldn't exceed its initial allocation except in rare cases
      and thus should be small (ideally exactly 1 element in size).
      
      In a hypothetical worst-case scenario wherein we have a 1 TiB heap and 4
      MiB arenas (note that the address ranges will never be at a smaller
      granularity than an arena, since arenas are always allocated
      contiguously), inUse would use at most 4 MiB of memory if the heap
      mappings were completely discontiguous (highly unlikely) with an
      additional 2 MiB leaked from previous allocations. Furthermore, the
      copies that are done to keep the inUse array sorted will copy at most 4
      MiB of memory in such a scenario, which, assuming a conservative copying
      rate of 5 GiB/s, amounts to about 800µs.
      
      However, note that in practice:
      1) Most 64-bit platforms have 64 MiB arenas.
      2) The copies should incur little-to-no page faults, meaning a copy rate
         closer to 25-50 GiB/s is expected.
      3) Go heaps are almost always mostly contiguous.
      
      Updates #35514.
      
      Change-Id: I3ad07f1c2b5b9340acf59ecc3b9ae09e884814fe
      Reviewed-on: https://go-review.googlesource.com/c/go/+/207757
      Run-TryBot: Michael Knyszek <mknyszek@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      9d78e75a
    • Bryan C. Mills's avatar
      net/http: use cancellation instead of a timeout in TestTransportProxyHTTPSConnectTimeout · ef3ef8fc
      Bryan C. Mills authored
      The use of a timeout in this test caused it to be flaky: if the
      timeout occurred before the connection was attempted, then the Accept
      call on the Listener could hang indefinitely, and its goroutine would
      not exit until that Listener was closed. That caused the test to fail.
      
      A longer timeout would make the test less flaky, but it would become
      even slower and would still be sensitive to timing.
      
      Instead, replace the timeout with an explicit Context cancellation
      after the CONNECT request has been read. That not only ensures that
      the cancellation occurs at the appropriate point, but also makes the
      test much faster: a test run with -count=1000 now executes in less
      than 2s on my machine, whereas before it took upwards of 50s.
      
      Fixes #36082
      Updates #28012
      
      Change-Id: I00c20d87365fd3d257774422f39d2acc8791febd
      Reviewed-on: https://go-review.googlesource.com/c/go/+/210857
      Run-TryBot: Bryan C. Mills <bcmills@google.com>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      ef3ef8fc
    • Andrew Stormont's avatar
      runtime: syscall_forkx on Solaris can return error on success · a1a67e63
      Andrew Stormont authored
      The syscall_forkx function returns the value of errno even on success.  This can be a problem when using cgo where an atfork handler might be registered; if the atfork handler does something which causes errno to be set the caller of syscall_forkx can be misled into thinking the fork has failed.  This causes the various exec functions in the runtime package to hang.
      
      Change-Id: Ia1842179226078a0cbbea33d541aa1187dc47f68
      GitHub-Last-Rev: 4dc4db75c82a826da9a50c323b7e3ddfe46ed6c0
      GitHub-Pull-Request: golang/go#36076
      Reviewed-on: https://go-review.googlesource.com/c/go/+/210742Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      a1a67e63
    • Dmitri Shuralyov's avatar
      doc: remove Release History pages (moved to x/website) · 9641acd6
      Dmitri Shuralyov authored
      These pages were moved to the x/website repo in CL 210797 (commit
      golang/website@9aef1eefbbe663d448b04b7cc1b2b995f4cf4c0b).
      Remove the old copies in this repo since they're no longer used.
      
      Updates #36075
      Updates #29206
      
      Change-Id: I6e3ffaebd92fa753cb5f3b21e4238edfb7f5f0e8
      Reviewed-on: https://go-review.googlesource.com/c/go/+/210798Reviewed-by: default avatarAlexander Rakoczy <alex@golang.org>
      9641acd6
    • Lorenz Bauer's avatar
      syscall: use SOCK_CLOEXEC when creating sockets · 9c8c27a3
      Lorenz Bauer authored
      LsfSocket, SetLsfPromisc and NetlinkRIB currently don't force the CLOEXEC
      flag on the sockets they create. While the former two functions are
      deprecated, NetlinkRIB is called by various functions related to
      net.Interface.
      
      Add a helper to create CLOEXEC sockets, and use it from SetLsfPromisc and
      NetlinkRIB. LsfSocket is unchanged since we don't want to break callers.
      
      Fixes #36053
      
      Change-Id: I72fe2b167996797698d8a44b0d28165045c42d3c
      Reviewed-on: https://go-review.googlesource.com/c/go/+/210517
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      9c8c27a3
  3. 10 Dec, 2019 6 commits
  4. 09 Dec, 2019 10 commits
  5. 07 Dec, 2019 2 commits
  6. 06 Dec, 2019 13 commits