Skip to content

G
go
Switch branch/tag
  1. 26 Oct, 2016 29 commits
  3. 25 Oct, 2016 11 commits
    • Matthew Dempsky's avatar
      cmd/compile: slightly regularize interface method types · d89b70d4
      Matthew Dempsky authored 
      Use a single *struct{} type instance rather than reconstructing one
for every declared/imported interface method. Minor allocations win:

name       old alloc/op    new alloc/op    delta
Template      41.8MB ± 0%     41.7MB ± 0%  -0.10%         (p=0.000 n=9+10)
Unicode       34.2MB ± 0%     34.2MB ± 0%    ~           (p=0.971 n=10+10)
GoTypes        123MB ± 0%      122MB ± 0%  -0.03%         (p=0.000 n=9+10)
Compiler       495MB ± 0%      495MB ± 0%  -0.01%        (p=0.000 n=10+10)

name       old allocs/op   new allocs/op   delta
Template        409k ± 0%       408k ± 0%  -0.13%        (p=0.000 n=10+10)
Unicode         354k ± 0%       354k ± 0%    ~           (p=0.516 n=10+10)
GoTypes        1.22M ± 0%      1.22M ± 0%  -0.03%        (p=0.009 n=10+10)
Compiler       4.43M ± 0%      4.43M ± 0%  -0.02%        (p=0.000 n=10+10)

Change-Id: Id3a4ca3dd09112bb96ccc982b06c9e79f661d31f
Reviewed-on: https://go-review.googlesource.com/32051Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      d89b70d4
    • Keith Randall's avatar
      Revert "Revert "cmd/compile: inline convI2E"" · c78d072c
      Keith Randall authored 
      This reverts commit 7dd9c385.

Reason for revert: Reverting the revert, which will re-enable the convI2E optimization.  We originally reverted the convI2E optimization because it was making the builder fail, but the underlying cause was later determined to be unrelated.

Original CL: https://go-review.googlesource.com/31260
Revert CL: https://go-review.googlesource.com/31310
Real bug: https://go-review.googlesource.com/c/25159
Real fix: https://go-review.googlesource.com/c/31316

Change-Id: I17237bb577a23a7675a5caab970ccda71a4124f2
Reviewed-on: https://go-review.googlesource.com/32023
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      c78d072c
    • Joe Tsai's avatar
      net/http: fix redirect logic to handle mutations of cookies · c60d9a33
      Joe Tsai authored 
      In the situation where the Client.Jar is set and the Request.Header
has cookies manually inserted, the redirect logic needs to be
able to apply changes to cookies from "Set-Cookie" headers to both
the Jar and the manually inserted Header cookies.

Since Header cookies lack information about the original domain
and path, the logic in this CL simply removes cookies from the
initial Header if any subsequent "Set-Cookie" matches. Thus,
in the event of cookie conflicts, the logic preserves the behavior
prior to change made in golang.org/cl/28930.

Fixes #17494
Updates #4800

Change-Id: I645194d9f97ff4d95bd07ca36de1d6cdf2f32429
Reviewed-on: https://go-review.googlesource.com/31435Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      c60d9a33
    • Matthew Dempsky's avatar
      cmd/compile: don't wrap numeric or type literals in OPAREN · 70d685dc
      Matthew Dempsky authored 
      It's only necessary to wrap named OTYPE or OLITERAL nodes, because
their line numbers reflect the line number of the declaration, rather
than use.

Saves a lot of wrapper nodes in composite-literal-heavy packages like
Unicode.

name       old alloc/op    new alloc/op    delta
Template      41.8MB ± 0%     41.8MB ± 0%  -0.07%        (p=0.000 n=10+10)
Unicode       36.6MB ± 0%     34.2MB ± 0%  -6.55%        (p=0.000 n=10+10)
GoTypes        123MB ± 0%      123MB ± 0%  -0.02%        (p=0.004 n=10+10)
Compiler       495MB ± 0%      495MB ± 0%  -0.03%        (p=0.000 n=10+10)

name       old allocs/op   new allocs/op   delta
Template        409k ± 0%       409k ± 0%  -0.05%        (p=0.029 n=10+10)
Unicode         371k ± 0%       354k ± 0%  -4.48%         (p=0.000 n=10+9)
GoTypes        1.22M ± 0%      1.22M ± 0%    ~           (p=0.075 n=10+10)
Compiler       4.44M ± 0%      4.44M ± 0%  -0.02%        (p=0.000 n=10+10)

Change-Id: Id1183170835125c778fb41b7e76d06d5ecd4f7a1
Reviewed-on: https://go-review.googlesource.com/32021
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      70d685dc
    • Matthew Dempsky's avatar
      cmd/compile: remove old lexer and parser · 57df2f80
      Matthew Dempsky authored 
      Change-Id: I7306d28930dc4538a3bee31ff5d22f3f40681ec5
Reviewed-on: https://go-review.googlesource.com/32020
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      57df2f80
    • Austin Clements's avatar
      runtime: eliminate allspans snapshot · 575b1dda
      Austin Clements authored 
      Now that sweeping and span marking use the sweep list, there's no need
for the work.spans snapshot of the allspans list. This change
eliminates the few remaining uses of it, which are either dead code or
can use allspans directly, and removes work.spans and its support
functions.

Change-Id: Id5388b42b1e68e8baee853d8eafb8bb4ff95bb43
Reviewed-on: https://go-review.googlesource.com/30537
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      575b1dda
    • Austin Clements's avatar
      runtime: make markrootSpans time proportional to in-use spans · c95a8e45
      Austin Clements authored 
      Currently markrootSpans iterates over all spans ever allocated to find
the in-use spans. Since we now have a list of in-use spans, change it
to iterate over that instead.

This, combined with the previous change, fixes #9265. Before these two
changes, blowing up the heap to 8GB and then shrinking it to a 0MB
live set caused the small-heap portion of the test to run 60x slower
than without the initial blowup. With these two changes, the time is
indistinguishable.

No significant effect on other benchmarks.

Change-Id: I4a27e533efecfb5d18cba3a87c0181a81d0ddc1e
Reviewed-on: https://go-review.googlesource.com/30536
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      c95a8e45
    • Austin Clements's avatar
      runtime: make sweep time proportional to in-use spans · f9497a67
      Austin Clements authored 
      Currently sweeping walks the list of all spans, which means the work
in sweeping is proportional to the maximum number of spans ever used.
If the heap was once large but is now small, this causes an
amortization failure: on a small heap, GCs happen frequently, but a
full sweep still has to happen in each GC cycle, which means we spent
a lot of time in sweeping.

Fix this by creating a separate list consisting of just the in-use
spans to be swept, so sweeping is proportional to the number of in-use
spans (which is proportional to the live heap). Specifically, we
create two lists: a list of unswept in-use spans and a list of swept
in-use spans. At the start of the sweep cycle, the swept list becomes
the unswept list and the new swept list is empty. Allocating a new
in-use span adds it to the swept list. Sweeping moves spans from the
unswept list to the swept list.

This fixes the amortization problem because a shrinking heap moves
spans off the unswept list without adding them to the swept list,
reducing the time required by the next sweep cycle.

Updates #9265. This fix eliminates almost all of the time spent in
sweepone; however, markrootSpans has essentially the same bug, so now
the test program from this issue spends all of its time in
markrootSpans.

No significant effect on other benchmarks.

Change-Id: Ib382e82790aad907da1c127e62b3ab45d7a4ac1e
Reviewed-on: https://go-review.googlesource.com/30535
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      f9497a67
    • Austin Clements's avatar
      runtime: expand comment on work.spans · 45baff61
      Austin Clements authored 
      Change-Id: I4b8a6f5d9bc5aba16026d17f99f3512dacde8d2d
Reviewed-on: https://go-review.googlesource.com/30534
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      45baff61
    • Austin Clements's avatar
      runtime: use len(h.spans) to indicate mapped region · 5915ce66
      Austin Clements authored 
      Currently we set the len and cap of h.spans to the full reserved
region of the address space and track the actual mapped region
separately in h.spans_mapped. Since we have both the len and cap at
our disposal, change things so len(h.spans) tracks how much of the
spans array is mapped and eliminate h.spans_mapped. This simplifies
mheap and means we'll get nice "index out of bounds" exceptions if we
do try to go off the end of the spans rather than a SIGSEGV.

Change-Id: I8ed9a1a9a844d90e9fd2e269add4704623dbdfe6
Reviewed-on: https://go-review.googlesource.com/30533
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      5915ce66
    • Austin Clements's avatar
      runtime: consolidate h_spans and mheap_.spans · 6b0f6680
      Austin Clements authored 
      Like h_allspans and mheap_.allspans, these were two ways of referring
to the spans array from when the runtime was split between C and Go.
Clean this up by making mheap_.spans a slice and eliminating h_spans.

Change-Id: I3aa7038d53c3a4252050aa33e468c48dfed0b70e
Reviewed-on: https://go-review.googlesource.com/30532
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      6b0f6680
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7