Skip to content

G
go
Switch branch/tag
  1. 16 Oct, 2019 8 commits
    • Bryan C. Mills's avatar
      Revert "cmd/compile, cmd/link, runtime: make defers low-cost through inline... · b76e6f88
      Bryan C. Mills authored 
      Revert "cmd/compile, cmd/link, runtime: make defers low-cost through inline code and extra funcdata"

This reverts CL 190098.

Reason for revert: broke several builders.

Change-Id: I69161352f9ded02537d8815f259c4d391edd9220
Reviewed-on: https://go-review.googlesource.com/c/go/+/201519
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: default avatarAustin Clements <austin@google.com>
Reviewed-by: default avatarDan Scales <danscales@google.com>
      b76e6f88
    • Emmanuel T Odeke's avatar
      io/ioutil: support predictable prefix,suffix for TempDir with * · 2718789b
      Emmanuel T Odeke authored 
      Allow TempDir to create directories with predictable
prefixes and suffixes, separated by the last "*", for example:
    "prefix*suffix"
will now expand to
    "prefix" + <RANDOM_VALUE> + "suffix"

RELNOTE=yes

Fixes #33805.

Change-Id: I85fa73ae6a684ce820d1810c82a60765eb9c4a42
Reviewed-on: https://go-review.googlesource.com/c/go/+/198488
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      2718789b
    • Dan Scales's avatar
      cmd/compile, cmd/link, runtime: make defers low-cost through inline code and extra funcdata · dad61637
      Dan Scales authored 
      Generate inline code at defer time to save the args of defer calls to unique
(autotmp) stack slots, and generate inline code at exit time to check which defer
calls were made and make the associated function/method/interface calls. We
remember that a particular defer statement was reached by storing in the deferBits
variable (always stored on the stack). At exit time, we check the bits of the
deferBits variable to determine which defer function calls to make (in reverse
order). These low-cost defers are only used for functions where no defers
appear in loops. In addition, we don't do these low-cost defers if there are too
many defer statements or too many exits in a function (to limit code increase).

When a function uses open-coded defers, we produce extra
FUNCDATA_OpenCodedDeferInfo information that specifies the number of defers, and
for each defer, the stack slots where the closure and associated args have been
stored. The funcdata also includes the location of the deferBits variable.
Therefore, for panics, we can use this funcdata to determine exactly which defers
are active, and call the appropriate functions/methods/closures with the correct
arguments for each active defer.

In order to unwind the stack correctly after a recover(), we need to add an extra
code segment to functions with open-coded defers that simply calls deferreturn()
and returns. This segment is not reachable by the normal function, but is returned
to by the runtime during recovery. We set the liveness information of this
deferreturn() to be the same as the liveness at the first function call during the
last defer exit code (so all return values and all stack slots needed by the defer
calls will be live).

I needed to increase the stackguard constant from 880 to 896, because of a small
amount of new code in deferreturn().

The -N flag disables open-coded defers. '-d defer' prints out the kind of defer
being used at each defer statement (heap-allocated, stack-allocated, or
open-coded).

Cost of defer statement  [ go test -run NONE -bench BenchmarkDefer$ runtime ]
  With normal (stack-allocated) defers only:         35.4  ns/op
  With open-coded defers:                             5.6  ns/op
  Cost of function call alone (remove defer keyword): 4.4  ns/op

Text size increase (including funcdata) for go cmd without/with open-coded defers:  0.09%

The average size increase (including funcdata) for only the functions that use
open-coded defers is 1.1%.

The cost of a panic followed by a recover got noticeably slower, since panic
processing now requires a scan of the stack for open-coded defer frames. This scan
is required, even if no frames are using open-coded defers:

Cost of panic and recover [ go test -run NONE -bench BenchmarkPanicRecover runtime ]
  Without open-coded defers:        62.0 ns/op
  With open-coded defers:           255  ns/op

A CGO Go-to-C-to-Go benchmark got noticeably faster because of open-coded defers:

CGO Go-to-C-to-Go benchmark [cd misc/cgo/test; go test -run NONE -bench BenchmarkCGoCallback ]
  Without open-coded defers:        443 ns/op
  With open-coded defers:           347 ns/op

Updates #14939 (defer performance)
Updates #34481 (design doc)

Change-Id: I51a389860b9676cfa1b84722f5fb84d3c4ee9e28
Reviewed-on: https://go-review.googlesource.com/c/go/+/190098Reviewed-by: default avatarAustin Clements <austin@google.com>
      dad61637
    • Fazlul Shahriar's avatar
      net: fix multicast and IPv6 related issues on Plan 9 · e94475ea
      Fazlul Shahriar authored 
      Fix issues that make these tests pass:
- TestDialerLocalAddr: return error if local address is not IPv4 for
"tcp4" network.
- TestInterfaceAddrs, TestInterfaceUnicastAddrs: don't assume each
interface has only one address. It may have more than one or none.
- TestConcurrentPreferGoResolversDial: should be skipped on Plan 9.
- TestListenMulticastUDP: remove IP from `announce` command and don't
mix IPv4 address with IPv6 address in `addmulti` command.

Fixes #34931

Change-Id: Ie0fdfe19ea282e5d6d6c938bf3c9139f8f5b0308
Reviewed-on: https://go-review.googlesource.com/c/go/+/201397
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      e94475ea
    • Ben Shi's avatar
      cmd/internal/obj/arm: remove NaCl related DATABUNDLE · f6c624a2
      Ben Shi authored 
      Updates golang/go#30439

Change-Id: Ieaf18b7cfd22a768eb1b7ac549ebc03637258876
Reviewed-on: https://go-review.googlesource.com/c/go/+/201377
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarKeith Randall <khr@golang.org>
      f6c624a2
    • Agniva De Sarker's avatar
      cmd/internal/obj/wasm,cmd/link/internal/wasm: add fast path for writeUleb128 · 03bb3e9a
      Agniva De Sarker authored 
      While building a simple hello world binary, there are total 858277 calls
to writeUleb during the assembler phase out of which 836625 (97%) are less than 7 bits.

Using a simple micro-benchmark like this:

func BenchmarkUleb(b *testing.B) {
	var buf bytes.Buffer
	for i := 0; i < b.N; i++ {
		writeUleb128(&buf, 42)
		buf.Reset()
	}
}

We get the following results with the fast path enabled.

name    old time/op  new time/op  delta
Uleb-4  8.45ns ± 2%  7.51ns ± 2%  -11.16%  (p=0.000 n=10+10)

Applying the time taken to the number of calls, we get roughly 6% improvement
in total time taken for writeUleb128.

We also apply the change to the function in linker to make it consistent.

Change-Id: I9fe8c41df1209f5f3aa7d8bd0181f1b0e536ceb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/201177
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      03bb3e9a
    • bill_ofarrell's avatar
      crypto/ecdsa: fix buffer size on s390x for ecdsa · 86f40a2e
      bill_ofarrell authored 
      I used too small a size for buffers, which can cause a panic in some testing.
The new buffer size is generous and sufficient for all purposes.

Fixes #34927
Fixes #34928

Change-Id: Icdbbfed5da87fe3757be40dfd23182b37ec62d58
Reviewed-on: https://go-review.googlesource.com/c/go/+/201317Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      86f40a2e
    • Cherry Zhang's avatar
      cmd/compile: on Wasm and AIX, let deferred nil function panic at invocation · c4817f5d
      Cherry Zhang authored 
      The Go spec requires

	If a deferred function value evaluates to nil, execution
	panics when the function is invoked, not when the "defer"
	statement is executed.

On Wasm and AIX, currently we actually emit a nil check at the
point of defer statement, which will make it panic too early.
This CL fixes this.

Also, on Wasm, now the nil function will be passed through
deferreturn to jmpdefer, which does an explicit nil check and
calls sigpanic if it is nil. This sigpanic, being called from
assembly, is ABI0. So change the assembler backend to also
handle sigpanic in ABI0.

Fixes #34926.
Updates #8047.

Change-Id: I28489a571cee36d2aef041f917b8cfdc31d557d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/201297Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      c4817f5d
  3. 15 Oct, 2019 12 commits
  5. 14 Oct, 2019 15 commits
  7. 13 Oct, 2019 2 commits
  9. 12 Oct, 2019 3 commits
    • Giovanni Bajo's avatar
      runtime: adjust expected error threshold in TestSelectFairness · e49ecaaa
      Giovanni Bajo authored 
      Make it a bit more relaxed on the expected fairness, as fastrand()
isn't a truly perfect random number generator.

Fixes #34808

Change-Id: Ib55b2bbe3c1bf63fb4f446fd1291eb1236efc33b
Reviewed-on: https://go-review.googlesource.com/c/go/+/200857
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarKeith Randall <khr@golang.org>
      e49ecaaa
    • Meng Zhuo's avatar
      net: use case-insensitive host string comparison in TestLookup* · 592d304b
      Meng Zhuo authored 
      Some nameservers alter the case of records as they return, e.g
.google.COM or .Google.com.
However according to RFC4343, DNS name should be treated in case insensitive fashion.
This CL will fix case sensitive testcases.

Fixes #34781

Change-Id: I5f9f6a41ddc1c61993e8d1f934ef0febddc3adc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/200277Reviewed-by: default avatarAndrei Tudor Călin <mail@acln.ro>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      592d304b
    • zdjones's avatar
      cmd/compile: make poset use sufficient conditions for OrderedOrEqual · 3c56eb40
      zdjones authored 
      When assessing whether A <= B, the poset's OrderedOrEqual has a passing
condition which permits A <= B, but is not sufficient to infer that A <= B.
This CL removes that incorrect passing condition.

Having identified that A and B are in the poset, the method will report that
A <= B if any of these three conditions are true:
 (1) A and B are the same node in the poset.
 	- This means we know that A == B.
 (2) There is a directed path, strict or not, from A -> B
 	- This means we know that, at least, A <= B, but A < B is possible.
 (3) There is a directed path from B -> A, AND that path has no strict edges.
 	- This means we know that B <= A, but do not know that B < A.

In condition (3), we do not have enough information to say that A <= B, rather
we only know that B == A (which satisfies A <= B) is possible. The way I
understand it, a strict edge shows a known, strictly-ordered relation (<) but
the lack of a strict edge does not show the lack of a strictly-ordered relation.

The difference is highlighted by the example in #34802, where a bounds check is
incorrectly removed by prove, such that negative indexes into a slice
succeed:

	n := make([]int, 1)
	for i := -1; i <= 0; i++ {
	    fmt.Printf("i is %d\n", i)
	    n[i] = 1  // No Bounds check, program runs, assignment to n[-1] succeeds!!
	}

When prove is checking the negative/failed branch from the bounds check at n[i],
in the signed domain we learn (0 > i || i >= len(n)). Because prove can't learn
the OR condition, we check whether we know that i is non-negative so we can
learn something, namely that i >= len(n). Prove uses the poset to check whether
we know that i is non-negative.  At this point the poset holds the following
relations as a directed graph:

	-1 <= i <= 0
	-1 < 0

In poset.OrderedOrEqual, we are testing for 0 <= i. In this case, condition (3)
above is true because there is a non-strict path from i -> 0, and that path
does NOT have any strict edges. Because this condition is true, the poset
reports to prove that i is known to be >= 0. Knowing, incorrectly, that i >= 0,
prove learns from the failed bounds check that i >= len(n) in the signed domain.

When the slice, n, was created, prove learned that len(n) == 1. Because i is
also the induction variable for the loop, upon entering the loop, prove previously
learned that i is in [-1,0]. So when prove attempts to learn from the failed
bounds check, it finds the new fact, i > len(n), unsatisfiable given that it
previously learned that i <= 0 and len(n) = 1.

Fixes #34802

Change-Id: I235f4224bef97700c3aa5c01edcc595eb9f13afc
Reviewed-on: https://go-review.googlesource.com/c/go/+/200759
Run-TryBot: Zach Jones <zachj1@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarGiovanni Bajo <rasky@develer.com>
Reviewed-by: default avatarKeith Randall <khr@golang.org>
      3c56eb40
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7