Skip to content

G
go
Switch branch/tag
  1. 06 Dec, 2019 3 commits
    • Ian Lance Taylor's avatar
      runtime: add Gosched to TestSelectStackAdjust loop · d2dec040
      Ian Lance Taylor authored 
      Give the runtime more of a chance to do other work in a tight loop.

Fixes #34693

Change-Id: I8df6173d2c93ecaccecf4520a6913b495787df78
Reviewed-on: https://go-review.googlesource.com/c/go/+/210217
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      d2dec040
    • Cherry Zhang's avatar
      cmd/compile: mark empty block preemptible · a037582e
      Cherry Zhang authored 
      Currently, a block's control instruction gets the liveness info
of the last Value in the block. However, for an empty block, the
control instruction gets the invalid liveness info and therefore
not preemptible. One example is empty infinite loop, which has
only a control instruction. The control instruction being non-
preemptible makes the whole loop non-preemptible.

Fix this by using a different, preemptible liveness info for
empty block's control. We can choose an arbitrary preemptible
liveness info, as at run time we don't really use the liveness
map at that instruction.

As before, if the last Value in the block is non-preemptible, so
is the block control. For example, the conditional branch in the
write barrier test block is still non-preemptible.

Also, only update liveness info if we are actually emitting
instructions. So zero-width Values' liveness info (which are
always invalid) won't affect the block control's liveness info.
For example, if the last Values in a block is a tuple-generating
operation and a Select, the block control instruction is still
preemptible.

Fixes #35923.

Change-Id: Ic5225f3254b07e4955f7905329b544515907642b
Reviewed-on: https://go-review.googlesource.com/c/go/+/209659
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: default avatarDavid Chase <drchase@google.com>
      a037582e
    • Cherry Zhang's avatar
      cmd/compile: don't fuse branches with side effects · 7673884a
      Cherry Zhang authored 
      Count Values with side effects but no use as live, and don't fuse
branches that contain such Values. (This can happen e.g. when it
is followed by an infinite loop.) Otherwise this may lead to
miscompilation (side effect fired at wrong condition) or ICE (two
stores live simultaneously).

Fixes #36005.

Change-Id: If202eae4b37cb7f0311d6ca120ffa46609925157
Reviewed-on: https://go-review.googlesource.com/c/go/+/210179Reviewed-by: default avatarKeith Randall <khr@golang.org>
      7673884a
  3. 05 Dec, 2019 13 commits
  5. 04 Dec, 2019 7 commits
  7. 03 Dec, 2019 3 commits
    • Michael Anthony Knyszek's avatar
      runtime: convert page allocator bitmap to sparse array · acf3ff2e
      Michael Anthony Knyszek authored 
      Currently the page allocator bitmap is implemented as a single giant
memory mapping which is reserved at init time and committed as needed.
This causes problems on systems that don't handle large uncommitted
mappings well, or institute low virtual address space defaults as a
memory limiting mechanism.

This change modifies the implementation of the page allocator bitmap
away from a directly-mapped set of bytes to a sparse array in same vein
as mheap.arenas. This will hurt performance a little but the biggest
gains are from the lockless allocation possible with the page allocator,
so the impact of this extra layer of indirection should be minimal.

In fact, this is exactly what we see:
    https://perf.golang.org/search?q=upload:20191125.5

This reduces the amount of mapped (PROT_NONE) memory needed on systems
with 48-bit address spaces to ~600 MiB down from almost 9 GiB. The bulk
of this remaining memory is used by the summaries.

Go processes with 32-bit address spaces now always commit to 128 KiB of
memory for the bitmap. Previously it would only commit the pages in the
bitmap which represented the range of addresses (lowest address to
highest address, even if there are unused regions in that range) used by
the heap.

Updates #35568.
Updates #35451.

Change-Id: I0ff10380156568642b80c366001eefd0a4e6c762
Reviewed-on: https://go-review.googlesource.com/c/go/+/207497
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarAustin Clements <austin@google.com>
Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      acf3ff2e
    • Xiangdong Ji's avatar
      cmd/vet: honor analyzer flags when running vet outside $GOROOT/src · 2ac1ca91
      Xiangdong Ji authored 
      Additional vet flags specified by user are discarded if 'go vet'
is invoked outside $GOROOT/src to check a package under $GOROOT
(including those under "vendor" of $GOROOT), fix it by avoiding the
overwriting, the logic of detemining if the package under vetting
comes from $GOROOT remains untouched.

Also checked 'go tool vet <options> <cfg>' and 'go vet <options>
<user pkg>', both worked w./w.o this fix.

Fixes #35837.

Change-Id: I549af7964e40440afd35f2d1971f77eee6f8de34
Reviewed-on: https://go-review.googlesource.com/c/go/+/209498
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      2ac1ca91
    • Ian Lance Taylor's avatar
      runtime: treat call from runtime as transient in TestDebugCall · 386b1a42
      Ian Lance Taylor authored 
      Fixes #32985

Change-Id: I5d504715dcc92d4f4f560ea2e843d9275f938685
Reviewed-on: https://go-review.googlesource.com/c/go/+/207620
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
Reviewed-by: default avatarAustin Clements <austin@google.com>
      386b1a42
  9. 02 Dec, 2019 5 commits
  11. 28 Nov, 2019 1 commit
    • Richard Miller's avatar
      runtime: on plan9 don't return substitute address for sysReserve · 8054b135
      Richard Miller authored 
      Plan 9 doesn't have a way to reserve virtual memory, so the
implementation of sysReserve allocates memory space (which won't
be backed with real pages until the virtual pages are referenced).
If the space is then freed with sysFree, it's not returned to
the OS (because Plan 9 doesn't allow shrinking a shared address
space), but it must be cleared to zeroes in case it's reallocated
subsequently.

This interacts badly with the way mallocinit on 64-bit machines
sets up the heap, calling sysReserve repeatedly for a very large
(64MB?) arena with a non-nil address hint, and then freeing the space
again because it doesn't have the expected alignment.  The
repeated clearing of multiple megabytes adds significant startup
time to every go program.

We correct this by restricting sysReserve to allocate memory only
when the caller doesn't provide an address hint.  If a hint is
provided, sysReserve will now return nil instead of allocating memory
at a different address.

Fixes #27744

Change-Id: Iae5a950adefe4274c4bc64dd9c740d19afe4ed1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/207917
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarDavid du Colombier <0intro@gmail.com>
      8054b135
  13. 27 Nov, 2019 8 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7