1. 17 Oct, 2017 11 commits
  2. 16 Oct, 2017 18 commits
  3. 15 Oct, 2017 3 commits
  4. 14 Oct, 2017 3 commits
    • Jed Denlea's avatar
      image/gif: write fewer, bigger blocks · 8b220d8e
      Jed Denlea authored
      The indexed bitmap of a frame is encoded into a GIF by first LZW
      compression, and then packaged by a simple block mechanism.  Each block
      of up-to-256 bytes starts with one byte, which indicates the size of the
      block (0x01-0xff). The sequence of blocks is terminated by a 0x00.
      
      While the format supports it, there is no good reason why any particular
      image should be anything but a sequence of 255-byte blocks with one last
      block less than 255-bytes.
      
      The old blockWriter implementation would not buffer between Write()s,
      meaning if the lzw Writer needs to flush more than one chunk of data via
      a Write, multiple short blocks might exist in the middle of a stream.
      
      Separate but related, the old implementation also forces lzw.NewWriter
      to allocate a bufio.Writer because the blockWriter is not an
      io.ByteWriter itself.  But, even though it doesn't effectively buffer
      data between Writes, it does make extra copies of sub-blocks during the
      course of writing them to the GIF's writer.
      
      Now, the blockWriter shall continue to use the encoder's [256]byte buf,
      but use it to effectively buffer a series of WriteByte calls from the
      lzw Writer.  Once a WriteByte fills the buffer, the staged block is
      Write()n to the underlying GIF writer.  After the lzw Writer is Closed,
      the blockWriter should also be closed, which will flush any remaining
      block along with the block terminator.
      
      BenchmarkEncode indicates slight improvements:
      
      name      old time/op    new time/op    delta
      Encode-8    7.71ms ± 0%    7.38ms ± 0%   -4.27%  (p=0.008 n=5+5)
      
      name      old speed      new speed      delta
      Encode-8   159MB/s ± 0%   167MB/s ± 0%   +4.46%  (p=0.008 n=5+5)
      
      name      old alloc/op   new alloc/op   delta
      Encode-8    84.1kB ± 0%    80.0kB ± 0%   -4.94%  (p=0.008 n=5+5)
      
      name      old allocs/op  new allocs/op  delta
      Encode-8      9.00 ± 0%      7.00 ± 0%  -22.22%  (p=0.008 n=5+5)
      
      Change-Id: I9eb9367d41d7c3d4d7f0adc9b720fc24fb50006a
      Reviewed-on: https://go-review.googlesource.com/68351Reviewed-by: 's avatarNigel Tao <nigeltao@golang.org>
      8b220d8e
    • Matthew Dempsky's avatar
      cmd/compile: omit ICE diagnostics after normal error messages · f3d4ff7d
      Matthew Dempsky authored
      After we detect errors, the AST is in a precarious state and more
      likely to trip useless ICE failures. Instead let the user fix any
      existing errors and see if the ICE persists.  This makes Fatalf more
      consistent with how panics are handled by hidePanic.
      
      While here, also fix detection for release versions: release version
      strings begin with "go" ("go1.8", "go1.9.1", etc), not "release".
      
      Fixes #22252.
      
      Change-Id: I1c400af62fb49dd979b96e1bf0fb295a81c8b336
      Reviewed-on: https://go-review.googlesource.com/70850
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      f3d4ff7d
    • Cherry Zhang's avatar
      cmd/compile: mark LoweredGetCallerPC rematerializeable · e01eac37
      Cherry Zhang authored
      The caller's PC is always available in the frame. We can just
      load it when needed, no need to spill.
      
      Change-Id: I9c0a525903e574bb4eec9fe53cbeb8c64321166a
      Reviewed-on: https://go-review.googlesource.com/70710
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      e01eac37
  5. 13 Oct, 2017 5 commits
    • Peter Wu's avatar
      crypto/tls: replace signatureAndHash by SignatureScheme. · d1bbdbe7
      Peter Wu authored
      Consolidate the signature and hash fields (SignatureAndHashAlgorithm in
      TLS 1.2) into a single uint16 (SignatureScheme in TLS 1.3 draft 21).
      This makes it easier to add RSASSA-PSS for TLS 1.2 in the future.
      
      Fields were named like "signatureAlgorithm" rather than
      "signatureScheme" since that name is also used throughout the 1.3 draft.
      
      The only new public symbol is ECDSAWithSHA1, other than that this is an
      internal change with no new functionality.
      
      Change-Id: Iba63d262ab1af895420583ac9e302d9705a7e0f0
      Reviewed-on: https://go-review.googlesource.com/62210Reviewed-by: 's avatarAdam Langley <agl@golang.org>
      d1bbdbe7
    • David Crawshaw's avatar
      cmd/link: use the correct module data on ppc64le · c996d07f
      David Crawshaw authored
      Fixes #22250
      
      Change-Id: I0e39d10ff6f0785cd22b0105de2d839e569db4b7
      Reviewed-on: https://go-review.googlesource.com/70810
      Run-TryBot: David Crawshaw <crawshaw@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      c996d07f
    • Austin Clements's avatar
      runtime: schedule fractional workers on all Ps · e09dbaa1
      Austin Clements authored
      Currently only a single P can run a fractional mark worker at a time.
      This doesn't let us spread out the load, so it gets concentrated on
      whatever unlucky P picks up the token to run a fractional worker. This
      can significantly delay goroutines on that P.
      
      This commit changes this scheduling rule so each P separately
      schedules fractional workers. This can significantly reduce the load
      on any individual P and allows workers to self-preempt earlier. It
      does have the downside that it's possible for all Ps to be in
      fractional workers simultaneously (an effect STW).
      
      Updates #21698.
      
      Change-Id: Ia1e300c422043fa62bb4e3dd23c6232d81e4419c
      Reviewed-on: https://go-review.googlesource.com/68574
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      e09dbaa1
    • Austin Clements's avatar
      runtime: preempt fractional worker after reaching utilization goal · 28e1a8e4
      Austin Clements authored
      Currently fractional workers run until preempted by the scheduler,
      which means they typically run for 20ms. During this time, all other
      goroutines on that P are blocked, which can introduce significant
      latency variance.
      
      This modifies fractional workers to self-preempt shortly after
      achieving the fractional utilization goal. In practice this means they
      preempt much sooner, and the scale of their preemption is on the order
      of how often the user goroutine block (so, if the application is
      compute-bound, the fractional workers will also run for long times,
      but if the application blocks frequently, the fractional workers will
      also preempt quickly).
      
      Fixes #21698.
      Updates #18534.
      
      Change-Id: I03a5ab195dae93154a46c32083c4bb52415d2017
      Reviewed-on: https://go-review.googlesource.com/68573
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      28e1a8e4
    • Austin Clements's avatar
      runtime: simplify fractional mark worker scheduler · b783930e
      Austin Clements authored
      We haven't used non-zero gcForcePreemptNS for ages. Remove it and
      declutter the code.
      
      Change-Id: Id5cc62f526d21ca394d2b6ca17d34a72959535da
      Reviewed-on: https://go-review.googlesource.com/68572
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      b783930e