Skip to content

G
golang
Switch branch/tag
  1. 17 Oct, 2017 12 commits
  3. 16 Oct, 2017 18 commits
  5. 15 Oct, 2017 3 commits
  7. 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
  9. 13 Oct, 2017 4 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