Skip to content

G
go
Switch branch/tag
  1. 23 May, 2019 12 commits
  3. 22 May, 2019 12 commits
  5. 21 May, 2019 10 commits
  7. 20 May, 2019 6 commits
    • Jay Conrod's avatar
      cmd/go: make 'go get -t' consider test dependencies in module mode · ab724d43
      Jay Conrod authored 
      Fixes #32037

Change-Id: I696fe2029e383746252f37fe8d30df71b5ac8a6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/177677
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      ab724d43
    • adarsh ravichandran's avatar
      math/bits: add example for OnesCount function · 776e1709
      adarsh ravichandran authored 
      Change-Id: Id87db9bed5e8715d554c1bf95c063d7d0a03c3e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/178117
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      776e1709
    • Keith Randall's avatar
      runtime: In Frames.Next, delay file/line lookup until just before return · c77a9e0a
      Keith Randall authored 
      That way we will never have to look up the file/line for the frame
that's next to be returned when the user stops calling Next.

For the benchmark from #32093:

name      old time/op  new time/op  delta
Helper-4   948ns ± 1%   836ns ± 3%  -11.89%  (p=0.000 n=9+9)

(#32093 was fixed with a more specific, and better, fix, but this
fix is much more general.)

Change-Id: I89e796f80c9706706d8d8b30eb14be3a8a442846
Reviewed-on: https://go-review.googlesource.com/c/go/+/178077
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      c77a9e0a
    • Michael Anthony Knyszek's avatar
      runtime: overhaul TestPhysicalMemoryUtilization · 5a903063
      Michael Anthony Knyszek authored 
      Currently, this test allocates many objects and relies on heap-growth
scavenging to happen unconditionally on heap-growth. However with the
new pacing system for the scavenging, this is no longer true and the
test is flaky.

So, this change overhauls TestPhysicalMemoryUtilization to check the
same aspect of the runtime, but in a much more robust way.

Firstly, it sets up a much more constrained scenario: only 5 objects are
allocated total with a maximum worst-case (i.e. the test fails) memory
footprint of about 16 MiB. The test is now aware that scavenging will
only happen if the heap growth causes us to push way past our scavenge
goal, which is based on the heap goal. So, it makes the holes in the
test much bigger and the actual retained allocations much smaller to
keep the heap goal at the heap's minimum size. It does this twice to
create exactly two unscavenged holes. Because the ratio between the size
of the "saved" objects and the "condemned" object is so small, two holes
are sufficient to create a consistent test.

Then, the test allocates one enormous object (the size of the 4 other
objects allocated, combined) with the intent that heap-growth scavenging
should kick in and scavenge the holes. The heap goal will rise after
this object is allocated, so it's very important we do all the
scavenging in a single allocation that exceeds the heap goal because
otherwise the rising heap goal could foil our test.

Finally, we check memory use relative to HeapAlloc as before. Since the
runtime should scavenge the entirety of the remaining holes,
theoretically there should be no more free and unscavenged memory.
However due to other allocations that may happen during the test we may
still see unscavenged memory, so we need to have some threshold. We keep
the current 10% threshold which, while arbitrary, is very conservative
and should easily account for any other allocations the test makes.

Before, we also had to ensure the allocations we were making looked
large relative to the size of a heap arena since newly-mapped memory was
considered unscavenged, and so that could significantly skew the test.
However, thanks to the fix for #32012 we were able to reduce memory use
to 16 MiB in the worst case.

Fixes #32010.

Change-Id: Ia38130481e292f581da7fa3289c98c99dc5394ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/177237Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      5a903063
    • Alex Myasoedov's avatar
      context: document CancelFunc to be safe for simultaneous use by multiple goroutines · 82ee4e7f
      Alex Myasoedov authored 
      Fixes #32145

Change-Id: If4c9dd3a2af748974141ad6e571f80efcbaad772
Reviewed-on: https://go-review.googlesource.com/c/go/+/177899Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      82ee4e7f
    • Shulhan's avatar
      internal/envcmd: print GO111MODULE when executing "go env" · 295c5662
      Shulhan authored 
      If we look at the issues in the past releases that are related
to go command that involved modules, its usually mention or ask about
the value of GO111MODULE, either in separate line or in separate
comment.

There are quite long time range before GO111MODULE will be removed
(unused).  The next release is still default to auto [1], and until Go
1.13 unsupported (two releases after that) there is about one and half
years after that.

Since the change is not that big (one line) [2], maybe temporary adding
it to "go env" give more clarity and benefit in issue reporting rather
than not.

[1] https://github.com/golang/go/issues/31857

Fixes #29656

Change-Id: I609ad6664774018e4f4147ec6158485172968e16
Reviewed-on: https://go-review.googlesource.com/c/go/+/176837
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      295c5662
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7