Skip to content

G
go
Switch branch/tag
  1. 19 Dec, 2019 2 commits
  3. 18 Dec, 2019 3 commits
  5. 17 Dec, 2019 5 commits
  7. 16 Dec, 2019 4 commits
  9. 15 Dec, 2019 1 commit
  11. 13 Dec, 2019 4 commits
  13. 12 Dec, 2019 3 commits
  15. 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
  17. 10 Dec, 2019 6 commits
  19. 09 Dec, 2019 4 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7