Skip to content

G
go
Switch branch/tag
  1. 11 Apr, 2015 3 commits
  3. 10 Apr, 2015 24 commits
  5. 09 Apr, 2015 13 commits
    • Austin Clements's avatar
      runtime: report next_gc for initial heap size in gctrace · cb10ff1e
      Austin Clements authored 
      Currently, the initial heap size reported in the gctrace line is the
heap_live right before sweep termination. However, we triggered GC
when heap_live reached next_gc, and there may have been significant
allocation between that point and the beginning of sweep
termination. Ideally these would be essentially the same, but
currently there's scheduler delay when readying the GC goroutine as
well as delay from background sweep finalization.

We should fix this delay, but in the mean time, to give the user a
better idea of how much the heap grew during the whole of garbage
collection, report the trigger rather than what the heap size happened
to be after the garbage collector finished rolling out of bed. This
will also be more useful for heap growth plots.

Change-Id: I08476b9fbcfb2de90592405e9c9f434dfb9eb1f8
Reviewed-on: https://go-review.googlesource.com/8512Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      cb10ff1e
    • Robert Griesemer's avatar
      math/big: better doc strings for ErrNaN functionality · d13f479d
      Robert Griesemer authored 
      Change-Id: Ia0944e7b47193465d3ec37fc8dc46dea9b5dcc6b
Reviewed-on: https://go-review.googlesource.com/8710Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      d13f479d
    • David Crawshaw's avatar
      runtime: add isarchive, set by the linker · d1b1eee2
      David Crawshaw authored 
      According to Go execution modes, a Go program compiled with
-buildmode=c-archive has a main function, but it is ignored on run.
This gives the runtime the information it needs not to run the main.

I have this working with pending linker changes on darwin/amd64.

Change-Id: I49bd7d65aa619ec847c464a872afa5deea7d4d30
Reviewed-on: https://go-review.googlesource.com/8701Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      d1b1eee2
    • Rob Pike's avatar
      log: logging an empty string should still print a line · d340b103
      Rob Pike authored 
      Print("") was printing a header but no line.

Fixes #9665.

Change-Id: Iac783187786065e1389ad6e8d7ef02c579ed7bd8
Reviewed-on: https://go-review.googlesource.com/8665Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      d340b103
    • Rob Pike's avatar
      encoding/gob: more checks for corrupted data · d64617fc
      Rob Pike authored 
      Also unify the tests where possible to make it easy to add more.

Fixes #10273.

Change-Id: Idfa4f4a5dcaa05974066bafe17bed6cdd2ebedb7
Reviewed-on: https://go-review.googlesource.com/8662Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      d64617fc
    • Dave Cheney's avatar
      runtime: add arm64 runtime.cmpstring and bytes.Compare · ee349b5d
      Dave Cheney authored 
      Add arm64 assembly implementation of runtime.cmpstring and bytes.Compare.

benchmark                                old ns/op     new ns/op     delta
BenchmarkCompareBytesEqual               98.0          27.5          -71.94%
BenchmarkCompareBytesToNil               9.38          10.0          +6.61%
BenchmarkCompareBytesEmpty               13.3          10.0          -24.81%
BenchmarkCompareBytesIdentical           98.0          27.5          -71.94%
BenchmarkCompareBytesSameLength          43.3          16.3          -62.36%
BenchmarkCompareBytesDifferentLength     43.4          16.3          -62.44%
BenchmarkCompareBytesBigUnaligned        6979680       1360979       -80.50%
BenchmarkCompareBytesBig                 6915995       1381979       -80.02%
BenchmarkCompareBytesBigIdentical        6781440       1327304       -80.43%

benchmark                             old MB/s     new MB/s     speedup
BenchmarkCompareBytesBigUnaligned     150.23       770.46       5.13x
BenchmarkCompareBytesBig              151.62       758.76       5.00x
BenchmarkCompareBytesBigIdentical     154.63       790.01       5.11x

* note, the machine we are benchmarking on has some issues. What is clear is
compared to a few days ago the old MB/s value has increased from ~115 to 150.
I'm less certain about the new MB/s number, which used to be close to 1Gb/s.

Change-Id: I4f31b2c7a06296e13912aacc958525632cb0450d
Reviewed-on: https://go-review.googlesource.com/8541Reviewed-by: default avatarAram Hăvărneanu <aram@mgk.ro>
Reviewed-by: default avatarDavid Crawshaw <crawshaw@golang.org>
      ee349b5d
    • Anthony Martin's avatar
      syscall: reduce the set of architecture-dependent files on Plan 9 · b9ba4ed2
      Anthony Martin authored 
      Change-Id: I98b172181c2fd85aa385341e28bc661dbc274252
Reviewed-on: https://go-review.googlesource.com/2167
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      b9ba4ed2
    • Daniel Morsing's avatar
      net/http: handle close/response race more gracefully · 39377013
      Daniel Morsing authored 
      There was a logical race in Transport.RoundTrip where a roundtrip with
a pending response would race with the channel for the connection
closing. This usually happened for responses with connection: close
and no body.

We handled this race by reading the close channel, setting a timer
for 100ms and if no response was returned before then, we would then
return an error.

This put a lower bound on how fast a connection could fail. We couldn't
fail a request faster than 100ms.

Reordering the channel operations gets rid of the logical race. If
the readLoop causes the connection to be closed, it would have put
its response into the return channel already and we can fetch it with
a non-blocking receive.

Change-Id: Idf09e48d7a0453d7de0120d3055d0ce5893a5428
Reviewed-on: https://go-review.googlesource.com/1787Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      39377013
    • Billie H. Cleek's avatar
      cmd/go: detect which VCS to use with Bitbucket when the API call fails. · a2d12201
      Billie H. Cleek authored 
            The API call will fail when Bitbucket repositories are private. In
that case, probe for the repository using vcsCmd.ping.

      Fixes #5375

Change-Id: Ia604ecf9014805579dfda4b5c8e627a52783d56e
Reviewed-on: https://go-review.googlesource.com/1910Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      a2d12201
    • Dmitry Vyukov's avatar
      cmd/gc: fix escape analysis of closures · 878a86a1
      Dmitry Vyukov authored 
      Fixes #10353

See test/escape2.go:issue10353. Previously new(int) did not escape to heap,
and so heap-allcated closure was referencing a stack var. This breaks
the invariant that heap must not contain pointers to stack.

Look at the following program:

package main

func main() {
	foo(new(int))
	bar(new(int))
}

func foo(x *int) func() {
	return func() {
		println(*x)
	}
}

// Models what foo effectively does.
func bar(x *int) *C {
	return &C{x}
}

type C struct {
	x *int
}

Without this patch escape analysis works as follows:

$ go build -gcflags="-m -m -m -l" esc.go
escflood:1: dst ~r1 scope:foo[0]
escwalk: level:0 depth:0  func literal( l(9) f(1) esc(no) ld(1)) scope:foo[1]
/tmp/live2.go:9: func literal escapes to heap
escwalk: level:0 depth:1 	 x( l(8) class(PPARAM) f(1) esc(no) ld(1)) scope:foo[1]
/tmp/live2.go:8: leaking param: x to result ~r1

escflood:2: dst ~r1 scope:bar[0]
escwalk: level:0 depth:0  &C literal( l(15) esc(no) ld(1)) scope:bar[1]
/tmp/live2.go:15: &C literal escapes to heap
escwalk: level:-1 depth:1 	 &C literal( l(15)) scope:bar[0]
escwalk: level:-1 depth:2 		 x( l(14) class(PPARAM) f(1) esc(no) ld(1)) scope:bar[1]
/tmp/live2.go:14: leaking param: x

/tmp/live2.go:5: new(int) escapes to heap
/tmp/live2.go:4: main new(int) does not escape

new(int) does not escape while being captured by the closure.
With this patch escape analysis of foo and bar works similarly:

$ go build -gcflags="-m -m -m -l" esc.go
escflood:1: dst ~r1 scope:foo[0]
escwalk: level:0 depth:0  &(func literal)( l(9)) scope:foo[0]
escwalk: level:-1 depth:1 	 func literal( l(9) f(1) esc(no) ld(1)) scope:foo[1]
/tmp/live2.go:9: func literal escapes to heap
escwalk: level:-1 depth:2 		 x( l(8) class(PPARAM) f(1) esc(no) ld(1)) scope:foo[1]
/tmp/live2.go:8: leaking param: x

escflood:2: dst ~r1 scope:bar[0]
escwalk: level:0 depth:0  &C literal( l(15) esc(no) ld(1)) scope:bar[1]
/tmp/live2.go:15: &C literal escapes to heap
escwalk: level:-1 depth:1 	 &C literal( l(15)) scope:bar[0]
escwalk: level:-1 depth:2 		 x( l(14) class(PPARAM) f(1) esc(no) ld(1)) scope:bar[1]
/tmp/live2.go:14: leaking param: x

/tmp/live2.go:4: new(int) escapes to heap
/tmp/live2.go:5: new(int) escapes to heap

Change-Id: Ifd14b7ae3fc11820e3b5eb31eb07f35a22ed0932
Reviewed-on: https://go-review.googlesource.com/8408Reviewed-by: default avatarRuss Cox <rsc@golang.org>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      878a86a1
    • Alex Brainman's avatar
      runtime: make windows exception handler code arch independent · 6e774fae
      Alex Brainman authored 
      Mainly it is simple copy. But I had to change amd64
lastcontinuehandler return value from uint32 to int32.
I don't remember how it happened to be uint32, but new
int32 is matching better with Windows documentation (LONG).
I don't think it matters one way or the others.

Change-Id: I6935224a2470ad6301e27590f2baa86c13bbe8d5
Reviewed-on: https://go-review.googlesource.com/8686Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      6e774fae
    • Matthew Brennan's avatar
      regexp: skip backtracker for long programs · a5130883
      Matthew Brennan authored 
      This update makes maxBacktrackLen return 0 if
len(prog.Inst) > maxBacktrackProg. This prevents an attempt to
backtrack against a nil bitstate.

Fixes #10319

Change-Id: Icdbeb2392782ccf66f9d0a70ea57af22fb93f01b
Reviewed-on: https://go-review.googlesource.com/8473Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      a5130883
    • Mikio Hara's avatar
      net/http: don't send IPv6 zone identifier in outbound request, per RFC 6874 · 957255f5
      Mikio Hara authored 
      When making a request to an IPv6 address with a zone identifier, for
exmaple [fe80::1%en0], RFC 6874 says HTTP clients must remove the zone
identifier "%en0" before writing the request for security reason.

This change removes any IPv6 zone identifer attached to URI in the Host
header field in requests.

Fixes #9544.

Change-Id: I7406bd0aa961d260d96f1f887c2e45854e921452
Reviewed-on: https://go-review.googlesource.com/3111Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      957255f5
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7