1. 28 Oct, 2016 37 commits
    • Austin Clements's avatar
      cmd/compile: use typedmemclr for zeroing if there are pointers · 8a7f0ad0
      Austin Clements authored
      Currently, zeroing generates an ssa.OpZero, which never has write
      barriers, even if the assignment is an OASWB. The hybrid barrier
      requires write barriers on zeroing, so change OASWB to generate an
      ssa.OpZeroWB when assigning the zero value, which turns into a
      typedmemclr.
      
      Updates #17503.
      
      Change-Id: Ib37ac5e39f578447dbd6b36a6a54117d5624784d
      Reviewed-on: https://go-review.googlesource.com/31451Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      8a7f0ad0
    • Austin Clements's avatar
      cmd/compile: lower slice clears to memclrHasPointers · 58e2edaf
      Austin Clements authored
      If a slice's backing store has pointers, we need to lower clears of
      that slice to memclrHasPointers instead of memclrNoHeapPointers.
      
      Updates #17503.
      
      Change-Id: I20750e4bf57f7b8862f3d898bfb32d964b91d07b
      Reviewed-on: https://go-review.googlesource.com/31450Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      58e2edaf
    • Russ Cox's avatar
      mime/multipart: simplify Part.Read · ef3df189
      Russ Cox authored
      The basic structure of Part.Read should be simple:
      do what you can with the current buffered data,
      reading more as you need it. Make it that way.
      
      Working entirely in the bufio.Reader's buffer eliminates
      the need for an additional bytes.Buffer.
      
      This structure should be easier to extend in the future as
      more special cases arise.
      
      Change-Id: I83cb24a755a1767c4c037f9ece6716460c3ecd01
      Reviewed-on: https://go-review.googlesource.com/32092
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      ef3df189
    • Austin Clements's avatar
      Revert "runtime/pprof: write profiles in protobuf format." · 14f3284d
      Austin Clements authored
      This reverts commit 7d14401b.
      
      Reason for revert: Doesn't build.
      
      Change-Id: I766179ab9225109d9232f783326e4d3843254980
      Reviewed-on: https://go-review.googlesource.com/32256Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      14f3284d
    • Russ Cox's avatar
      net: add (*UnixListener).SetUnlinkOnClose · eb88b3ee
      Russ Cox authored
      Let users control whether unix listener socket file is unlinked on close.
      
      Fixes #13877.
      
      Change-Id: I9d1cb47e31418d655f164d15c67e188656a67d1c
      Reviewed-on: https://go-review.googlesource.com/32099
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      eb88b3ee
    • Russ Cox's avatar
      net: only remove Unix domain socket file on the first call to Close · 13558c41
      Russ Cox authored
      Fixes #17131.
      
      Change-Id: I60b381687746fadce12ef18a190cbe3f435172f2
      Reviewed-on: https://go-review.googlesource.com/32098
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarQuentin Smith <quentin@golang.org>
      13558c41
    • Austin Clements's avatar
      runtime, cmd/compile: rename memclr -> memclrNoHeapPointers · 87e48c5a
      Austin Clements authored
      Since barrier-less memclr is only safe in very narrow circumstances,
      this commit renames memclr to avoid accidentally calling memclr on
      typed memory. This can cause subtle, non-deterministic bugs, so it's
      worth some effort to prevent. In the near term, this will also prevent
      bugs creeping in from any concurrent CLs that add calls to memclr; if
      this happens, whichever patch hits master second will fail to compile.
      
      This also adds the other new memclr variants to the compiler's
      builtin.go to minimize the churn on that binary blob. We'll use these
      in future commits.
      
      Updates #17503.
      
      Change-Id: I00eead049f5bd35ca107ea525966831f3d1ed9ca
      Reviewed-on: https://go-review.googlesource.com/31369Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      87e48c5a
    • Austin Clements's avatar
      runtime: make fixalloc zero allocations on reuse · ae3bb4a5
      Austin Clements authored
      Currently fixalloc does not zero memory it reuses. This is dangerous
      with the hybrid barrier if the type may contain heap pointers, since
      it may cause us to observe a dead heap pointer on reuse. It's also
      error-prone since it's the only allocator that doesn't zero on
      allocation (mallocgc of course zeroes, but so do persistentalloc and
      sysAlloc). It's also largely pointless: for mcache, the caller
      immediately memclrs the allocation; and the two specials types are
      tiny so there's no real cost to zeroing them.
      
      Change fixalloc to zero allocations by default.
      
      The only type we don't zero by default is mspan. This actually
      requires that the spsn's sweepgen survive across freeing and
      reallocating a span. If we were to zero it, the following race would
      be possible:
      
      1. The current sweepgen is 2. Span s is on the unswept list.
      
      2. Direct sweeping sweeps span s, finds it's all free, and releases s
         to the fixalloc.
      
      3. Thread 1 allocates s from fixalloc. Suppose this zeros s, including
         s.sweepgen.
      
      4. Thread 1 calls s.init, which sets s.state to _MSpanDead.
      
      5. On thread 2, background sweeping comes across span s in allspans
         and cas's s.sweepgen from 0 (sg-2) to 1 (sg-1). Now it thinks it
         owns it for sweeping. 6. Thread 1 continues initializing s.
         Everything breaks.
      
      I would like to fix this because it's obviously confusing, but it's a
      subtle enough problem that I'm leaving it alone for now. The solution
      may be to skip sweepgen 0, but then we have to think about wrap-around
      much more carefully.
      
      Updates #17503.
      
      Change-Id: Ie08691feed3abbb06a31381b94beb0a2e36a0613
      Reviewed-on: https://go-review.googlesource.com/31368Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      ae3bb4a5
    • Austin Clements's avatar
      runtime: make _MSpanDead be the zero state · f4dcc9b2
      Austin Clements authored
      Currently the zero value of an mspan is in the "in use" state. This
      seems like a bad idea in general. But it's going to wreak havoc when
      we make fixalloc zero allocations: even "freed" mspan objects are
      still on the allspans list and still get looked at by the garbage
      collector. Hence, if we leave the mspan states the way they are,
      allocating a span that reuses old memory will temporarily pass that
      span (which is visible to GC!) through the "in use" state, which can
      cause "unswept span" panics.
      
      Fix all of this by making the zero state "dead".
      
      Updates #17503.
      
      Change-Id: I77c7ac06e297af4b9e6258bc091c37abe102acc3
      Reviewed-on: https://go-review.googlesource.com/31367Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      f4dcc9b2
    • Austin Clements's avatar
      runtime: use typedmemclr for typed memory · aa581f51
      Austin Clements authored
      The hybrid barrier requires distinguishing typed and untyped memory
      even when zeroing because the *current* contents of the memory matters
      even when overwriting.
      
      This commit introduces runtime.typedmemclr and runtime.memclrHasPointers
      as a typed memory clearing functions parallel to runtime.typedmemmove.
      Currently these simply call memclr, but with the hybrid barrier we'll
      need to shade any pointers we're overwriting. These will provide us
      with the necessary hooks to do so.
      
      Updates #17503.
      
      Change-Id: I74478619f8907825898092aaa204d6e4690f27e6
      Reviewed-on: https://go-review.googlesource.com/31366Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      aa581f51
    • Austin Clements's avatar
      runtime: parallelize STW mcache flushing · a475a38a
      Austin Clements authored
      Currently all mcaches are flushed in a single STW root job. This takes
      about 5 µs per P, but since it's done sequentially it adds about
      5*GOMAXPROCS µs to the STW.
      
      Fix this by parallelizing the job. Since there are exactly GOMAXPROCS
      mcaches to flush, this parallelizes quite nicely and brings the STW
      latency cost down to a constant 5 µs (assuming GOMAXPROCS actually
      reflects the number of CPUs).
      
      Updates #17503.
      
      Change-Id: Ibefeb1c2229975d5137c6e67fac3b6c92103742d
      Reviewed-on: https://go-review.googlesource.com/32033Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      a475a38a
    • Josh Bleecher Snyder's avatar
      cmd/compile: don't alloc Name/Param for unresolved syms · 20edeabc
      Josh Bleecher Snyder authored
      ONONAME nodes generated from unresolved symbols don't need Params.
      They only need Names to store Iota; move Iota to Node.Xoffset.
      While we're here, change iota to int64 to reduce casting.
      
      Passes toolstash -cmp.
      
      name       old alloc/op     new alloc/op     delta
      Template       39.9MB ± 0%      39.7MB ± 0%  -0.39%        (p=0.000 n=19+20)
      Unicode        30.9MB ± 0%      30.7MB ± 0%  -0.35%        (p=0.000 n=20+20)
      GoTypes         119MB ± 0%       118MB ± 0%  -0.42%        (p=0.000 n=20+20)
      Compiler        464MB ± 0%       461MB ± 0%  -0.54%        (p=0.000 n=19+20)
      
      name       old allocs/op    new allocs/op    delta
      Template         386k ± 0%        383k ± 0%  -0.62%        (p=0.000 n=20+20)
      Unicode          323k ± 0%        321k ± 0%  -0.49%        (p=0.000 n=20+20)
      GoTypes         1.16M ± 0%       1.15M ± 0%  -0.67%        (p=0.000 n=20+20)
      Compiler        4.09M ± 0%       4.05M ± 0%  -0.95%        (p=0.000 n=20+20)
      
      Change-Id: Ib27219a0d0405def1b4dadacf64935ba12d10a94
      Reviewed-on: https://go-review.googlesource.com/32237
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarMatthew Dempsky <mdempsky@google.com>
      20edeabc
    • unknown's avatar
      runtime/pprof: write profiles in protobuf format. · 7d14401b
      unknown authored
      Added functions with suffix proto and stuff from pprof tool to translate
      to protobuf. Done as the profile proto is more extensible than the legacy
      pprof format and is pprof's preferred profile format. Large part was taken
      from https://github.com/google/pprof tool. Tested by hand and compared the
      result with translated by pprof tool, profiles are identical.
      Fixes #16093
      Change-Id: I5acdb2809cab0d16ed4694fdaa7b8ddfd68df11e
      Reviewed-on: https://go-review.googlesource.com/30556
      Run-TryBot: Michael Matloob <matloob@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarMichael Matloob <matloob@golang.org>
      7d14401b
    • Austin Clements's avatar
      runtime: fix preemption of root marking jobs · d70b0fe6
      Austin Clements authored
      The current logic in gcDrain conflates non-blocking with preemptible
      draining for root jobs. As a result, if you do a non-blocking (but
      *not* preemptible) drain, like dedicated workers do, the root job
      drain will stop if preempted and fall through to heap marking jobs,
      which won't stop until it fails to get a heap marking job.
      
      This commit fixes the condition on root marking jobs so they only stop
      when preempted if the drain is preemptible.
      
      Coincidentally, this also fixes a nil pointer dereference if we call
      gcDrain with gcDrainNoBlock and without a user G, since it tries to
      get the preempt flag from the nil user G. This combination never
      happens right now, but will in the future.
      
      Change-Id: Ia910ec20a9b46237f7926969144a33b1b4a7b2f9
      Reviewed-on: https://go-review.googlesource.com/32291
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      d70b0fe6
    • Austin Clements's avatar
      runtime/trace, internal/trace: script to collect canned traces · e14b0219
      Austin Clements authored
      This adds support to the runtime/trace test for saving traces
      collected by its tests to disk and a script in internal/trace that
      uses this to collect canned traces for the trace test suite. This can
      be used to add to the test suite when we introduce a new trace format
      version.
      
      Change-Id: Id9ac1ff312235bf02f982fdfff8a827f54035758
      Reviewed-on: https://go-review.googlesource.com/32290
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      e14b0219
    • Joe Tsai's avatar
      bytes, strings: optimize for ASCII sets · 9a8c6953
      Joe Tsai authored
      In a large codebase within Google, there are thousands of uses of:
      	ContainsAny|IndexAny|LastIndexAny|Trim|TrimLeft|TrimRight
      
      An analysis of their usage shows that over 97% of them only use character
      sets consisting of only ASCII symbols.
      
      Uses of ContainsAny|IndexAny|LastIndexAny:
      	 6% are 1   character  (e.g., "\n" or " ")
      	58% are 2-4 characters (e.g., "<>" or "\r\n\t ")
      	24% are 5-9 characters (e.g., "()[]*^$")
      	10% are 10+ characters (e.g., "+-=&|><!(){}[]^\"~*?:\\/ ")
      We optimize for ASCII sets, which are commonly used to search for
      "control" characters in some string. We don't optimize for the
      single character scenario since IndexRune or IndexByte could be used.
      
      Uses of Trim|TrimLeft|TrimRight:
      	71% are 1   character  (e.g., "\n" or " ")
      	14% are 2   characters (e.g., "\r\n")
      	10% are 3-4 characters (e.g., " \t\r\n")
      	 5% are 10+ characters (e.g., "0123456789abcdefABCDEF")
      We optimize for the single character case with a simple closured function
      that only checks for that character's value. We optimize for the medium
      and larger sets using a 16-byte bit-map representing a set of ASCII characters.
      
      The benchmarks below have the following suffix name "%d:%d" where the first
      number is the length of the input and the second number is the length
      of the charset.
      
      == bytes package ==
      benchmark                            old ns/op     new ns/op     delta
      BenchmarkIndexAnyASCII/1:1-4         5.09          5.23          +2.75%
      BenchmarkIndexAnyASCII/1:2-4         5.81          5.85          +0.69%
      BenchmarkIndexAnyASCII/1:4-4         7.22          7.50          +3.88%
      BenchmarkIndexAnyASCII/1:8-4         11.0          11.1          +0.91%
      BenchmarkIndexAnyASCII/1:16-4        17.5          17.8          +1.71%
      BenchmarkIndexAnyASCII/16:1-4        36.0          34.0          -5.56%
      BenchmarkIndexAnyASCII/16:2-4        46.6          36.5          -21.67%
      BenchmarkIndexAnyASCII/16:4-4        78.0          40.4          -48.21%
      BenchmarkIndexAnyASCII/16:8-4        136           47.4          -65.15%
      BenchmarkIndexAnyASCII/16:16-4       254           61.5          -75.79%
      BenchmarkIndexAnyASCII/256:1-4       542           388           -28.41%
      BenchmarkIndexAnyASCII/256:2-4       705           382           -45.82%
      BenchmarkIndexAnyASCII/256:4-4       1089          386           -64.55%
      BenchmarkIndexAnyASCII/256:8-4       1994          394           -80.24%
      BenchmarkIndexAnyASCII/256:16-4      3843          411           -89.31%
      BenchmarkIndexAnyASCII/4096:1-4      8522          5873          -31.08%
      BenchmarkIndexAnyASCII/4096:2-4      11253         5861          -47.92%
      BenchmarkIndexAnyASCII/4096:4-4      17824         5883          -66.99%
      BenchmarkIndexAnyASCII/4096:8-4      32053         5871          -81.68%
      BenchmarkIndexAnyASCII/4096:16-4     60512         5888          -90.27%
      BenchmarkTrimASCII/1:1-4             79.5          70.8          -10.94%
      BenchmarkTrimASCII/1:2-4             79.0          105           +32.91%
      BenchmarkTrimASCII/1:4-4             79.6          109           +36.93%
      BenchmarkTrimASCII/1:8-4             78.8          118           +49.75%
      BenchmarkTrimASCII/1:16-4            80.2          132           +64.59%
      BenchmarkTrimASCII/16:1-4            243           116           -52.26%
      BenchmarkTrimASCII/16:2-4            243           171           -29.63%
      BenchmarkTrimASCII/16:4-4            243           176           -27.57%
      BenchmarkTrimASCII/16:8-4            241           184           -23.65%
      BenchmarkTrimASCII/16:16-4           238           199           -16.39%
      BenchmarkTrimASCII/256:1-4           2580          840           -67.44%
      BenchmarkTrimASCII/256:2-4           2603          1175          -54.86%
      BenchmarkTrimASCII/256:4-4           2572          1188          -53.81%
      BenchmarkTrimASCII/256:8-4           2550          1191          -53.29%
      BenchmarkTrimASCII/256:16-4          2585          1208          -53.27%
      BenchmarkTrimASCII/4096:1-4          39773         12181         -69.37%
      BenchmarkTrimASCII/4096:2-4          39946         17231         -56.86%
      BenchmarkTrimASCII/4096:4-4          39641         17179         -56.66%
      BenchmarkTrimASCII/4096:8-4          39835         17175         -56.88%
      BenchmarkTrimASCII/4096:16-4         40229         17215         -57.21%
      
      == strings package ==
      benchmark                            old ns/op     new ns/op     delta
      BenchmarkIndexAnyASCII/1:1-4         5.94          4.97          -16.33%
      BenchmarkIndexAnyASCII/1:2-4         5.94          5.55          -6.57%
      BenchmarkIndexAnyASCII/1:4-4         7.45          7.21          -3.22%
      BenchmarkIndexAnyASCII/1:8-4         10.8          10.6          -1.85%
      BenchmarkIndexAnyASCII/1:16-4        17.4          17.2          -1.15%
      BenchmarkIndexAnyASCII/16:1-4        36.4          32.2          -11.54%
      BenchmarkIndexAnyASCII/16:2-4        49.6          34.6          -30.24%
      BenchmarkIndexAnyASCII/16:4-4        77.5          37.9          -51.10%
      BenchmarkIndexAnyASCII/16:8-4        138           45.5          -67.03%
      BenchmarkIndexAnyASCII/16:16-4       241           59.1          -75.48%
      BenchmarkIndexAnyASCII/256:1-4       509           378           -25.74%
      BenchmarkIndexAnyASCII/256:2-4       720           381           -47.08%
      BenchmarkIndexAnyASCII/256:4-4       1142          384           -66.37%
      BenchmarkIndexAnyASCII/256:8-4       1999          391           -80.44%
      BenchmarkIndexAnyASCII/256:16-4      3735          403           -89.21%
      BenchmarkIndexAnyASCII/4096:1-4      7973          5824          -26.95%
      BenchmarkIndexAnyASCII/4096:2-4      11432         5809          -49.19%
      BenchmarkIndexAnyASCII/4096:4-4      18327         5819          -68.25%
      BenchmarkIndexAnyASCII/4096:8-4      33059         5828          -82.37%
      BenchmarkIndexAnyASCII/4096:16-4     59703         5817          -90.26%
      BenchmarkTrimASCII/1:1-4             71.9          71.8          -0.14%
      BenchmarkTrimASCII/1:2-4             73.3          103           +40.52%
      BenchmarkTrimASCII/1:4-4             71.8          106           +47.63%
      BenchmarkTrimASCII/1:8-4             71.2          113           +58.71%
      BenchmarkTrimASCII/1:16-4            71.6          128           +78.77%
      BenchmarkTrimASCII/16:1-4            152           116           -23.68%
      BenchmarkTrimASCII/16:2-4            160           168           +5.00%
      BenchmarkTrimASCII/16:4-4            172           170           -1.16%
      BenchmarkTrimASCII/16:8-4            200           177           -11.50%
      BenchmarkTrimASCII/16:16-4           254           193           -24.02%
      BenchmarkTrimASCII/256:1-4           1438          864           -39.92%
      BenchmarkTrimASCII/256:2-4           1551          1195          -22.95%
      BenchmarkTrimASCII/256:4-4           1770          1200          -32.20%
      BenchmarkTrimASCII/256:8-4           2195          1216          -44.60%
      BenchmarkTrimASCII/256:16-4          3054          1224          -59.92%
      BenchmarkTrimASCII/4096:1-4          21726         12557         -42.20%
      BenchmarkTrimASCII/4096:2-4          23586         17508         -25.77%
      BenchmarkTrimASCII/4096:4-4          26898         17510         -34.90%
      BenchmarkTrimASCII/4096:8-4          33714         17595         -47.81%
      BenchmarkTrimASCII/4096:16-4         47429         17700         -62.68%
      
      The benchmarks added test the worst case. For IndexAny, that is when the
      charset matches none of the input. For Trim, it is when the charset matches
      all of the input.
      
      Change-Id: I970874d101a96b33528fc99b165379abe58cf6ea
      Reviewed-on: https://go-review.googlesource.com/31593
      Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: 's avatarMartin Möhrmann <martisch@uos.de>
      9a8c6953
    • Russ Cox's avatar
      html/template, text/template: drop defined template list from errors · ef3a9f2d
      Russ Cox authored
      The report in #17414 points out that if you have many many templates,
      then this is an overwhelming list and just hurts the signal-to-noise ratio of the error.
      
      Even the test of the old behavior also supports the idea that this is noise:
      
      	template: empty: "empty" is an incomplete or empty template; defined templates are: "secondary"
      
      The chance that someone mistyped "secondary" as "empty" is slim at best.
      
      Similarly, the compiler does not augment an error like 'unknown variable x'
      by dumping the full list of all the known variables.
      
      For all these reasons, drop the list.
      
      Fixes #17414.
      
      Change-Id: I78f92d2c591df7218385fe723a4abc497913acf8
      Reviewed-on: https://go-review.googlesource.com/32116
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRob Pike <r@golang.org>
      ef3a9f2d
    • Russ Cox's avatar
      runtime: skip TestMemmoveOverflow if mmap of needed page fails · 54f691d6
      Russ Cox authored
      Fixes #16731.
      
      Change-Id: I6d393357973d008ab7cf5fb264acb7d38c9354eb
      Reviewed-on: https://go-review.googlesource.com/32104
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      54f691d6
    • Robert Griesemer's avatar
      spec: update operator and delimiter section · 7fd6b925
      Robert Griesemer authored
      Follow-up on https://go-review.googlesource.com/30601.
      
      Change-Id: I51b603a6c4877b571e83cd7c4e78a8988cc831ca
      Reviewed-on: https://go-review.googlesource.com/32310Reviewed-by: 's avatarRob Pike <r@golang.org>
      7fd6b925
    • Josh Chorlton's avatar
      net/http: fix cookie Expires minimum year to 1601 instead of Epoch year 1970 · d86a6ef0
      Josh Chorlton authored
      Following RFC 6265 Section 5.1.1.5, ensure that the minimum
      year for which an Expires value is valid and can be included in
      the cookie's string, is 1601 instead of the Epoch year 1970.
      
      A detailed specification for parsing the Expiry field is at:
      https://tools.ietf.org/html/rfc6265#section-5.2.1
      
      I stumbled across this bug due to this StackOverflow answer
      that recommends setting the Expiry to the Epoch:
      http://stackoverflow.com/a/5285982
      
      Fixes #17632
      
      Change-Id: I3c1bdf821d369320334a5dc1e4bf22783cbfe9fc
      Reviewed-on: https://go-review.googlesource.com/32142Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      d86a6ef0
    • Russ Cox's avatar
      mime/quotedprintable: accept = not followed by 2 hex digits as literal equals · a8e86d99
      Russ Cox authored
      This lets quotedprintable handle some inputs found in the wild,
      most notably generated by "Microsoft CDO for Exchange 2000",
      and it also matches how Python's quopri package handles these inputs.
      
      Fixes #13219.
      
      Change-Id: I69d400659d01b6ea0f707b7053d61803a85b4799
      Reviewed-on: https://go-review.googlesource.com/32174Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      a8e86d99
    • Jaana Burcu Dogan's avatar
      net/http/httptrace: refer http.Client users to the blog post · 864859d2
      Jaana Burcu Dogan authored
      Fixes #17152.
      
      Change-Id: I4dd5e505c65f3efe736e46d3781cccf31d7f574f
      Reviewed-on: https://go-review.googlesource.com/32117Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      864859d2
    • Brad Fitzpatrick's avatar
      doc: remove mention of Go 1.6.3 working on Sierra · fc2507db
      Brad Fitzpatrick authored
      We thought it would at the time, but then Beta 4 changed the ABI
      again, so it wasn't true in practice.
      
      Fixes #17643
      
      Change-Id: I36b747bd69a56adc7291fa30d6bffdf67ab8741b
      Reviewed-on: https://go-review.googlesource.com/32238Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      fc2507db
    • Austin Clements's avatar
      runtime, cmd/trace: track goroutines blocked on GC assists · 6da83c6f
      Austin Clements authored
      Currently when a goroutine blocks on a GC assist, it emits a generic
      EvGoBlock event. Since assist blocking events and, in particular, the
      length of the blocked assist queue, are important for diagnosing GC
      behavior, this commit adds a new EvGoBlockGC event for blocking on a
      GC assist. The trace viewer uses this event to report a "waiting on
      GC" count in the "Goroutines" row. This makes sense because, unlike
      other blocked goroutines, these goroutines do have work to do, so
      being blocked on a GC assist is quite similar to being in the
      "runnable" state, which we also report in the trace viewer.
      
      Change-Id: Ic21a326992606b121ea3d3d00110d8d1fdc7a5ef
      Reviewed-on: https://go-review.googlesource.com/30704
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      6da83c6f
    • Austin Clements's avatar
      cmd/trace: track each G's state explicitly · 640e9169
      Austin Clements authored
      Currently the trace tool tracks an overall counts of goroutine states,
      but not the states of any individual goroutine. We're about to add
      more sophisticated blocked-state tracking, so add this tracking and
      base the state counts off the tracked goroutine states.
      
      Change-Id: I943ed61782436cf9540f4ee26c5561715c5b4a1d
      Reviewed-on: https://go-review.googlesource.com/30703
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      640e9169
    • Austin Clements's avatar
      runtime, cmd/trace: annotate different mark worker types · 68348394
      Austin Clements authored
      Currently mark workers are shown in the trace as regular goroutines
      labeled "runtime.gcBgMarkWorker". That's somewhat unhelpful to an end
      user because of the opaque label and particularly unhelpful to runtime
      developers because it doesn't distinguish the different types of mark
      workers.
      
      Fix this by introducing a variant of the GoStart event called
      GoStartLabel that lets the runtime indicate a label for a goroutine
      execution span and using this to label mark worker executions as "GC
      (<mode>)" in the trace viewer.
      
      Since this bumps the trace version to 1.8, we also add test data for
      1.7 traces.
      
      Change-Id: Id7b9c0536508430c661ffb9e40e436f3901ca121
      Reviewed-on: https://go-review.googlesource.com/30702
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      68348394
    • Cherry Zhang's avatar
      cmd/compile: make LR allocatable in non-leaf functions on ARM · f9238a76
      Cherry Zhang authored
      The mechanism is initially introduced (and reviewed) in CL 30597
      on S390X.
      
      Reduce number of "spilled value remains" by 0.4% in cmd/go.
      
      Disabled on ARMv5 because LR is clobbered almost everywhere with
      inserted softfloat calls.
      
      Change-Id: I2934737ce2455909647ed2118fe2bd6f0aa5ac52
      Reviewed-on: https://go-review.googlesource.com/32178
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      f9238a76
    • Cherry Zhang's avatar
      cmd/internal/obj/mips: materialize float constant 0 from zero register · 4f1ca8b6
      Cherry Zhang authored
      Materialize float constant 0 from integer zero register, instead
      of loading from constant pool.
      
      Change-Id: Ie4728895b9d617bec2a29d15729c0efaa10eedbb
      Reviewed-on: https://go-review.googlesource.com/32109
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      4f1ca8b6
    • Carlos Eduardo Seo's avatar
      cmd/asm, cmd/internal/obj/ppc64: Add vector scalar (VSX) registers and instructions · 0acefdbe
      Carlos Eduardo Seo authored
      The current implementation for Power architecture does not include the vector
      scalar (VSX) registers.  This adds the 63 VSX registers and the most commonly
      used instructions: load/store VSX vector/scalar, move to/from VSR, logical
      operations, select, merge, splat, permute, shift, FP-FP conversion, FP-integer
      conversion and integer-FP conversion.
      
      Change-Id: I0f7572d2359fe7f3ea0124a1eb1b0bebab33649e
      Reviewed-on: https://go-review.googlesource.com/30510Reviewed-by: 's avatarLynn Boger <laboger@linux.vnet.ibm.com>
      Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      Run-TryBot: David Chase <drchase@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      0acefdbe
    • David Crawshaw's avatar
      runtime: pass windows float syscall args via XMM · 9c02c756
      David Crawshaw authored
      Based on the calling convention documented in:
      
      	https://msdn.microsoft.com/en-us/library/zthk2dkh.aspx
      
      and long-used in golang.org/x/mobile/gl via some fixup asm:
      
      	https://go.googlesource.com/mobile/+/master/gl/work_windows_amd64.s
      
      Fixes #6510
      
      Change-Id: I97e81baaa2872bcd732b1308915eb66f1ba2168f
      Reviewed-on: https://go-review.googlesource.com/32173
      Run-TryBot: David Crawshaw <crawshaw@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarAlex Brainman <alex.brainman@gmail.com>
      Reviewed-by: 's avatarMinux Ma <minux@golang.org>
      9c02c756
    • Austin Clements's avatar
      runtime: fix preemption of fractional and idle mark workers · dd500193
      Austin Clements authored
      Currently, gcDrain looks for the preemption flag at getg().preempt.
      However, commit d6625caf moved mark worker draining to the system
      stack, which means getg() returns the g0, which never has the preempt
      flag set, so idle and fractional workers don't get preempted after
      10ms and just run until they run out of work. As a result, if there's
      enough idle time, GC becomes effectively STW.
      
      Fix this by looking for the preemption flag on getg().m.curg, which
      will always be the user G (where the preempt flag is set), regardless
      of whether gcDrain is running on the user or the g0 stack.
      
      Change-Id: Ib554cf49a705b86ccc3d08940bc869f868c50dd2
      Reviewed-on: https://go-review.googlesource.com/32251
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      dd500193
    • Peter Weinberger's avatar
      runtime: Profile goroutines holding contended mutexes. · ca922b6d
      Peter Weinberger authored
      runtime.SetMutexProfileFraction(n int) will capture 1/n-th of stack
      traces of goroutines holding contended mutexes if n > 0. From runtime/pprof,
      pprot.Lookup("mutex").WriteTo writes the accumulated
      stack traces to w (in essentially the same format that blocking
      profiling uses).
      
      Change-Id: Ie0b54fa4226853d99aa42c14cb529ae586a8335a
      Reviewed-on: https://go-review.googlesource.com/29650Reviewed-by: 's avatarAustin Clements <austin@google.com>
      ca922b6d
    • Martin Möhrmann's avatar
      cmd/compile: move stringtoslicebytetmp to the backend · b679665a
      Martin Möhrmann authored
      - removes the runtime function stringtoslicebytetmp
      - removes the generation of calls to stringtoslicebytetmp from the frontend
      - adds handling of OSTRARRAYBYTETMP in the backend
      
      This reduces binary sizes and avoids function call overhead.
      
      Change-Id: Ib9988d48549cee663b685b4897a483f94727b940
      Reviewed-on: https://go-review.googlesource.com/32158Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: 's avatarMatthew Dempsky <mdempsky@google.com>
      Reviewed-by: 's avatarJosh Bleecher Snyder <josharian@gmail.com>
      Run-TryBot: Martin Möhrmann <martisch@uos.de>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      b679665a
    • Alex Brainman's avatar
      runtime/cgo: do not link threads lib by default on windows · f595848e
      Alex Brainman authored
      I do not know why it is included. All tests pass without it.
      
      Change-Id: I839076ee131816dfd177570a902c69fe8fba5022
      Reviewed-on: https://go-review.googlesource.com/32144
      Run-TryBot: Minux Ma <minux@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      f595848e
    • Josh Bleecher Snyder's avatar
      cmd/compile: eliminate more allocs in newblock · 79d2115e
      Josh Bleecher Snyder authored
      name       old allocs/op    new allocs/op    delta
      Template         389k ± 0%        386k ± 0%  -0.84%        (p=0.000 n=10+10)
      Unicode          323k ± 0%        323k ± 0%  -0.25%        (p=0.000 n=10+10)
      GoTypes         1.17M ± 0%       1.16M ± 0%  -0.93%        (p=0.000 n=10+10)
      Compiler        4.13M ± 0%       4.09M ± 0%  -1.05%        (p=0.000 n=10+10)
      
      Change-Id: I6c00850d07511c2e65761c7373fc3df738499105
      Reviewed-on: https://go-review.googlesource.com/32235
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      Reviewed-by: 's avatarDavid Crawshaw <crawshaw@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      79d2115e
    • Josh Bleecher Snyder's avatar
      cmd/compile: combine slice allocations in newblock · 23d762c1
      Josh Bleecher Snyder authored
      name       old allocs/op    new allocs/op    delta
      Template         394k ± 0%        391k ± 0%  -0.80%        (p=0.000 n=10+10)
      Unicode          350k ± 0%        349k ± 0%  -0.27%        (p=0.000 n=10+10)
      GoTypes         1.18M ± 0%       1.17M ± 0%  -0.92%        (p=0.000 n=10+10)
      Compiler        4.18M ± 0%       4.14M ± 0%  -1.05%        (p=0.000 n=10+10)
      
      
      Change-Id: I838a4e2110afe6496c535b9a0ec5aa882d63a707
      Reviewed-on: https://go-review.googlesource.com/32223
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      23d762c1
    • Nigel Tao's avatar
      image/png: implement grayscale transparency. · caba0bd1
      Nigel Tao authored
      Change-Id: Ib9309ee499fc51be2662d778430ee30089822e57
      Reviewed-on: https://go-review.googlesource.com/32143Reviewed-by: 's avatarRob Pike <r@golang.org>
      caba0bd1
  2. 27 Oct, 2016 3 commits
    • Matthew Dempsky's avatar
      cmd/compile: stop adding implicit OKEY nodes · bba1ac4f
      Matthew Dempsky authored
      Keys are uncommon in array and slice literals, and normalizing
      OARRAYLIT and OSLICELIT nodes to always use OKEY ends up not reducing
      complexity much. Instead, only create OKEY nodes to represent explicit
      keys, and recalculate implicit keys when/where necessary.
      
      Fixes #15350.
      
      name       old time/op     new time/op     delta
      Template       299ms ± 9%      299ms ±12%    ~           (p=0.694 n=28+30)
      Unicode        165ms ± 7%      162ms ± 9%    ~           (p=0.084 n=27+27)
      GoTypes        950ms ± 9%      963ms ± 5%    ~           (p=0.301 n=30+29)
      Compiler       4.23s ± 7%      4.17s ± 7%    ~           (p=0.057 n=29+27)
      
      name       old user-ns/op  new user-ns/op  delta
      Template        389M ±15%       400M ±12%    ~           (p=0.202 n=30+29)
      Unicode         246M ±21%       232M ±22%  -5.76%        (p=0.006 n=28+29)
      GoTypes        1.34G ± 8%      1.34G ± 7%    ~           (p=0.775 n=28+30)
      Compiler       5.91G ± 6%      5.87G ± 7%    ~           (p=0.298 n=28+29)
      
      name       old alloc/op    new alloc/op    delta
      Template      41.2MB ± 0%     41.2MB ± 0%    ~           (p=0.085 n=30+30)
      Unicode       34.0MB ± 0%     31.5MB ± 0%  -7.28%        (p=0.000 n=30+29)
      GoTypes        121MB ± 0%      121MB ± 0%    ~           (p=0.657 n=30+30)
      Compiler       511MB ± 0%      511MB ± 0%  -0.01%        (p=0.001 n=29+29)
      
      name       old allocs/op   new allocs/op   delta
      Template        390k ± 0%       390k ± 0%    ~           (p=0.225 n=30+29)
      Unicode         318k ± 0%       293k ± 0%  -8.03%        (p=0.000 n=30+29)
      GoTypes        1.16M ± 0%      1.16M ± 0%    ~           (p=0.745 n=30+30)
      Compiler       4.35M ± 0%      4.35M ± 0%    ~           (p=0.105 n=30+30)
      
      Change-Id: I6310739a0bfdb54f1ab8a460b2c03615ad1ff5bc
      Reviewed-on: https://go-review.googlesource.com/32221Reviewed-by: 's avatarJosh Bleecher Snyder <josharian@gmail.com>
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      bba1ac4f
    • Nigel Tao's avatar
      image/png: implement truecolor transparency. · 4951c793
      Nigel Tao authored
      Change-Id: I99b9a51db29d514ebaa9c1cfde65c0b5184c0f42
      Reviewed-on: https://go-review.googlesource.com/32140Reviewed-by: 's avatarRob Pike <r@golang.org>
      4951c793
    • Cherry Zhang's avatar
      math/big: flip long/short flag on TestFloat32Distribution · 0dabbcdc
      Cherry Zhang authored
      It looks like a typo in CL 30707.
      
      Change-Id: Ia2d013567dbd1a49901d9be0cd2d5a103e6e38cf
      Reviewed-on: https://go-review.googlesource.com/32187
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      0dabbcdc