Skip to content

G
go
Switch branch/tag
  1. 12 Oct, 2016 2 commits
  3. 11 Oct, 2016 18 commits
  5. 10 Oct, 2016 5 commits
  7. 09 Oct, 2016 7 commits
  9. 08 Oct, 2016 2 commits
  11. 07 Oct, 2016 6 commits
    • Michael Munday's avatar
      cmd/{asm,compile}: replace TESTB op with CMPWconst on s390x · 45b26a93
      Michael Munday authored 
      TESTB was implemented as AND $0xff, Rx, REGTMP. Unfortunately there
is no 3-operand AND-with-immediate instruction and so it was emulated
by the assembler using two instructions.

This CL uses CMPW instead of AND and also optimizes CMPW to use
the chi instruction where possible.

Overall this CL reduces the size of the .text section of the
bin/go binary by ~2%.

Change-Id: Ic335c29fc1129378fcbb1265bfb10f5b744a0f3f
Reviewed-on: https://go-review.googlesource.com/30690
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      45b26a93
    • Keith Randall's avatar
      cmd/compile: use standard dom tree in nilcheckelim · f4e37c8e
      Keith Randall authored 
      No need to build a bespoke dom tree here when we might
have one cached already.  The allocations for the dom tree
were also more expensive than they needed to be.

Fixes #12021

Change-Id: I6a967880aee03660ad6fc293f8fc783779cae11d
Reviewed-on: https://go-review.googlesource.com/30671
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      f4e37c8e
    • Andrew Pogrebnoy's avatar
      cmd/compile: fix choice of phi building algorithm · 433be563
      Andrew Pogrebnoy authored 
      The algorithm for placing a phi nodes in small functions now
unreachable. This patch fix that.

Change-Id: I253d745b414fa12ee0719459c28e78a69c6861ae
Reviewed-on: https://go-review.googlesource.com/30106
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarKeith Randall <khr@golang.org>
      433be563
    • Austin Clements's avatar
      cmd/trace: label mark termination spans as such · 94589054
      Austin Clements authored 
      Currently these are labeled "MARK", which was accurate in the STW
collector, but these really indicate mark termination now, since
marking happens for the full duration of the concurrent GC. Re-label
them as "MARK TERMINATION" to clarify this.

Change-Id: Ie98bd961195acde49598b4fa3f9e7d90d757c0a6
Reviewed-on: https://go-review.googlesource.com/30018Reviewed-by: default avatarDmitry Vyukov <dvyukov@google.com>
      94589054
    • Austin Clements's avatar
      cmd/trace: move process-wide GC events to their own row · eed309f5
      Austin Clements authored 
      Currently, the process-wide GC state is attributed to the P that
happened to perform the allocation that exceeded the GC trigger. This
is pretty arbitrary and makes it hard to see when GC is running since
the GC spans are intermingled with a lot of other trace noise.

The current display is particularly confusing because it creates three
sub-rows in the P row that can overlap each other. Usually a P has
just two sub-rows: one showing the current G and another showing that
G's activity. However, because GC is attributed to a proc, it winds up
as a third row that neither subsumes nor is subsumed by any other row.
This in turn screws up the trace's layout and results in overlapping
events.

Fix these problems by creating a new dedicated row like the existing
"Network" and "Timer" rows and displaying process-wide GC events in
this row. Mark termination and sweep events still appear in their
respective P rows because these are meaningfully attributed.

Change-Id: Ie1a1c6cf8c446e4b043f10f3968f91ff1b546d15
Reviewed-on: https://go-review.googlesource.com/30017Reviewed-by: default avatarDmitry Vyukov <dvyukov@google.com>
      eed309f5
    • Austin Clements's avatar
      runtime: make next_gc ^0 when GC is disabled · fa9b57bb
      Austin Clements authored 
      When GC is disabled, we set gcpercent to -1. However, we still use
gcpercent to compute several values, such as next_gc and gc_trigger.
These calculations are meaningless when gcpercent is -1 and result in
meaningless values. This is okay in a sense because we also never use
these values if gcpercent is -1, but they're confusing when exposed to
the user, for example via MemStats or the execution trace. It's
particularly unfortunate in the execution trace because it attempts to
plot the underflowed value of next_gc, which scales all useful
information in the heap row into oblivion.

Fix this by making next_gc ^0 when gcpercent < 0. This has the
advantage of being true in a way: next_gc is effectively infinite when
gcpercent < 0. We can also detect this special value when updating the
execution trace and report next_gc as 0 so it doesn't blow up the
display of the heap line.

Change-Id: I4f366e4451f8892a4908da7b2b6086bdc67ca9a9
Reviewed-on: https://go-review.googlesource.com/30016Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      fa9b57bb
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7