Skip to content

G
go
Switch branch/tag
  1. 13 Jan, 2016 8 commits
    • Ilya Tocar's avatar
      cmd/internal/obj/x86: add new instructions, cleanup. · 1d1f2fb4
      Ilya Tocar authored 
      Add several instructions that were used via BYTE and use them.
Instructions added: PEXTRB, PEXTRD, PEXTRQ, PINSRB, XGETBV, POPCNT.

Change-Id: I5a80cd390dc01f3555dbbe856a475f74b5e6df65
Reviewed-on: https://go-review.googlesource.com/18593
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      1d1f2fb4
    • Mikio Hara's avatar
      net: LookupAddr("127.0.0.1") is "localhost" not "localhost." on Plan 9 and Windows · ceeb52d8
      Mikio Hara authored 
      This change applies the fix for #13564 to Plan 9 and Windows.
Also enables Lookup API test cases on builders.

Updates #13564.

Change-Id: I863f03c7cb6fbe58b3a55223bfa0ac5f9bf9c3df
Reviewed-on: https://go-review.googlesource.com/18559
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      ceeb52d8
    • Brad Fitzpatrick's avatar
      net/http2: update bundled http2 · 771da539
      Brad Fitzpatrick authored 
      Update bundled http2 to git rev 76365a4 for https://golang.org/issue/18571

Fixes golang/go#13924

Change-Id: Ibb48cd6935b35d9965df70fb8761be5986d79ffc
Reviewed-on: https://go-review.googlesource.com/18591Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      771da539
    • Brad Fitzpatrick's avatar
      crypto/tls: don't block in Conn.Close if Writes are in-flight · 4ffba768
      Brad Fitzpatrick authored 
      Conn.Close sends an encrypted "close notify" to signal secure EOF.
But writing that involves acquiring mutexes (handshake mutex + the
c.out mutex) and writing to the network. But if the reason we're
calling Conn.Close is because the network is already being
problematic, then Close might block, waiting for one of those mutexes.

Instead of blocking, and instead of introducing new API (at least for
now), distinguish between a normal Close (one that sends a secure EOF)
and a resource-releasing destructor-style Close based on whether there
are existing Write calls in-flight.

Because io.Writer and io.Closer aren't defined with respect to
concurrent usage, a Close with active Writes is already undefined, and
should only be used during teardown after failures (e.g. deadlines or
cancelations by HTTP users). A normal user will do a Write then
serially do a Close, and things are unchanged for that case.

This should fix the leaked goroutines and hung net/http.Transport
requests when there are network errors while making TLS requests.

Change-Id: If3f8c69d6fdcebf8c70227f41ad042ccc3f20ac9
Reviewed-on: https://go-review.googlesource.com/18572Reviewed-by: default avatarAdam Langley <agl@golang.org>
Reviewed-by: default avatarRuss Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      4ffba768
    • David Chase's avatar
      cmd/compile: better modeling of escape across loop levels · e779bfa5
      David Chase authored 
      Brief background on "why heap allocate".  Things can be
forced to the heap for the following reasons:

1) address published, hence lifetime unknown.
2) size unknown/too large, cannot be stack allocated
3) multiplicity unknown/too large, cannot be stack allocated
4) reachable from heap (not necessarily published)

The bug here is a case of failing to enforce 4) when an
object Y was reachable from a heap allocation X forced
because of 3).  It was found in the case of a closure
allocated within a loop (X) and assigned to a variable
outside the loop (multiplicity unknown) where the closure
also captured a map (Y) declared outside the loop (reachable
from heap). Note the variable declared outside the loop (Y)
is not published, has known size, and known multiplicity
(one). The only reason for heap allocation is that it was
reached from a heap allocated item (X), but because that was
not forced by publication, it has to be tracked by loop
level, but escape-loop level was not tracked and thus a bug
results.

The fix is that when a heap allocation is newly discovered,
use its looplevel as the minimum loop level for downstream
escape flooding.

Every attempt to generalize this bug to X-in-loop-
references-Y-outside loop succeeded, so the fix was aimed
to be general.  Anywhere that loop level forces heap
allocation, the loop level is tracked.  This is not yet
tested for all possible X and Y, but it is correctness-
conservative and because it caused only one trivial
regression in the escape tests, it is probably also
performance-conservative.

The new test checks the following:
1) in the map case, that if fn escapes, so does the map.
2) in the map case, if fn does not escape, neither does the map.
3) in the &x case, that if fn escapes, so does &x.
4) in the &x case, if fn does not escape, neither does &x.

Fixes #13799.

Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb
Reviewed-on: https://go-review.googlesource.com/18234
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      e779bfa5
    • Michael Hudson-Doyle's avatar
      runtime/internal/atomic: use //go:noinline to prevent inlining, not assembly nop · 04093286
      Michael Hudson-Doyle authored 
      A bit cleanuppy for 1.6 maybe, but something I happened to notice.

Change-Id: I70f3b48445f4f527d67f7b202b6171195440b09f
Reviewed-on: https://go-review.googlesource.com/18550Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      04093286
    • Russ Cox's avatar
      runtime: make NumGoroutine and Stack agree not to include system goroutines · fac8202c
      Russ Cox authored 
      [Repeat of CL 18343 with build fixes.]

Before, NumGoroutine counted system goroutines and Stack (usually) didn't show them,
which was inconsistent and confusing.

To resolve which way they should be consistent, it seems like

	package main
	import "runtime"
	func main() { println(runtime.NumGoroutine()) }

should print 1 regardless of internal runtime details. Make it so.

Fixes #11706.

Change-Id: If26749fec06aa0ff84311f7941b88d140552e81d
Reviewed-on: https://go-review.googlesource.com/18432Reviewed-by: default avatarAustin Clements <austin@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
      fac8202c
    • Russ Cox's avatar
      math/big: fix Exp(x, x, x) for certain large x · 1e066cad
      Russ Cox authored 
      Fixes #13907.

Change-Id: Ieaa5183f399b12a9177372212adf481c8f0b4a0d
Reviewed-on: https://go-review.googlesource.com/18491Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
Reviewed-by: default avatarVlad Krasnov <vlad@cloudflare.com>
Reviewed-by: default avatarAdam Langley <agl@golang.org>
      1e066cad
  3. 12 Jan, 2016 6 commits
  5. 11 Jan, 2016 8 commits
  7. 10 Jan, 2016 5 commits
  9. 09 Jan, 2016 5 commits
  11. 08 Jan, 2016 8 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7