Skip to content

G
go
Switch branch/tag
  1. 15 Oct, 2015 6 commits
  3. 14 Oct, 2015 9 commits
  5. 13 Oct, 2015 5 commits
  7. 12 Oct, 2015 4 commits
  9. 11 Oct, 2015 2 commits
  11. 10 Oct, 2015 4 commits
  13. 09 Oct, 2015 10 commits
    • Ian Lance Taylor's avatar
      cmd/link: remove -W option · a0c7f579
      Ian Lance Taylor authored 
      The -W option has not worked since Go 1.3.  It is not documented.  When
it did work, it generated useful output, but it was for human viewing;
there was no reason to write a script that passes the -W option, so it's
unlikely that anybody is using it today.

Change-Id: I4769f1ffd308a48324a866592eb7fd79a4cdee54
Reviewed-on: https://go-review.googlesource.com/15701Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      a0c7f579
    • Robert Griesemer's avatar
      cmd/compile/internal/gc: make funcsyms a []*Node · a2119aca
      Robert Griesemer authored 
      Remove another use of NodeList.

Change-Id: Ice07eff862caf715f722dec7829006bf71715b07
Reviewed-on: https://go-review.googlesource.com/15432Reviewed-by: default avatarDave Cheney <dave@cheney.net>
      a2119aca
    • Nodir Turakulov's avatar
      cmd/go: print all warnings to stderr · 88150935
      Nodir Turakulov authored 
      All warnings in cmd/go are printed using fmt.Fprintf(os.Stderr...)
except one in test.go which is printed using log.Printf.
This is a minor inconsistency.

Change-Id: Ib470d318810b44b86e6cfaa77e9a556a5ad94069
Reviewed-on: https://go-review.googlesource.com/15657
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      88150935
    • Austin Clements's avatar
      runtime: assist before allocating · 65aa2da6
      Austin Clements authored 
      Currently, when the mutator allocates, the runtime first allocates the
memory and then, if that G has done "enough" allocation, the runtime
checks whether the G has assist debt to pay off and, if so, pays it
off. This approach leads to under-assisting, where a G can allocate a
large region (or many small regions) before paying for it, or can even
exit with outstanding debt.

This commit flips this around so that a G always acquires enough
credit for an allocation before it can perform that allocation. We
continue to amortize the cost of assists by requiring that they
over-assist when triggered to build up credit for many allocations.

Fixes #11967.

Change-Id: Idac9f11133b328535667674d837be72c23ebd899
Reviewed-on: https://go-review.googlesource.com/15409Reviewed-by: default avatarRick Hudson <rlh@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
      65aa2da6
    • Austin Clements's avatar
      runtime: directly track GC assist balance · 89c341c5
      Austin Clements authored 
      Currently we track the per-G GC assist balance as two monotonically
increasing values: the bytes allocated by the G this cycle (gcalloc)
and the scan work performed by the G this cycle (gcscanwork). The
assist balance is hence assistRatio*gcalloc - gcscanwork.

This works, but has two important downsides:

1) It requires floating-point math to figure out if a G is in debt or
   not. This makes it inappropriate to check for assist debt in the
   hot path of mallocgc, so we only do this when a G allocates a new
   span. As a result, Gs can operate "in the red", leading to
   under-assist and extended GC cycle length.

2) Revising the assist ratio during a GC cycle can lead to an "assist
   burst". If you think of plotting the scan work performed versus
   heaps size, the assist ratio controls the slope of this line.
   However, in the current system, the target line always passes
   through 0 at the heap size that triggered GC, so if the runtime
   increases the assist ratio, there has to be a potentially large
   assist to jump from the current amount of scan work up to the new
   target scan work for the current heap size.

This commit replaces this approach with directly tracking the GC
assist balance in terms of allocation credit bytes. Allocating N bytes
simply decreases this by N and assisting raises it by the amount of
scan work performed divided by the assist ratio (to get back to
bytes).

This will make it cheap to figure out if a G is in debt, which will
let us efficiently check if an assist is necessary *before* performing
an allocation and hence keep Gs "in the black".

This also fixes assist bursts because the assist ratio is now in terms
of *remaining* work, rather than work from the beginning of the GC
cycle. Hence, the plot of scan work versus heap size becomes
continuous: we can revise the slope, but this slope always starts from
where we are right now, rather than where we were at the beginning of
the cycle.

Change-Id: Ia821c5f07f8a433e8da7f195b52adfedd58bdf2c
Reviewed-on: https://go-review.googlesource.com/15408Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      89c341c5
    • Austin Clements's avatar
      runtime: ensure minimum heap distance via heap goal · 9e77c898
      Austin Clements authored 
      Currently we ensure a minimum heap distance of 1MB when computing the
assist ratio. Rather than enforcing this minimum on the heap distance,
it makes more sense to enforce that the heap goal itself is at least
1MB over the live heap size at the beginning of GC. Currently the two
approaches are semantically equivalent, but this will let us switch to
basing the assist ratio on current heap distance rather than the
initial heap distance, since we can't enforce this minimum on the
current heap distance (the GC may never finish because the goal posts
will always be 1MB away).

Change-Id: I0027b1c26a41a0152b01e5b67bdb1140d43ee903
Reviewed-on: https://go-review.googlesource.com/15604Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      9e77c898
    • Austin Clements's avatar
      runtime: update gcController.scanWork regularly · 8e8219de
      Austin Clements authored 
      Currently, gcController.scanWork is updated as lazily as possible
since it is only read at the end of the GC cycle. We're about to read
it during the GC cycle to improve the assist ratio revisions, so
modify gcDrain* to regularly flush to gcController.scanWork in much
the same way as we regularly flush to gcController.bgScanCredit.

One consequence of this is that it's difficult to keep gcw.scanWork
monotonic, so we give up on that and simply return the amount of scan
work done by gcDrainN rather than calculating it in the caller.

Change-Id: I7b50acdc39602f843eed0b5c6d2dacd7e762b81d
Reviewed-on: https://go-review.googlesource.com/15407Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      8e8219de
    • Austin Clements's avatar
      runtime: control background scan credit flushing with flag · c18b163c
      Austin Clements authored 
      Currently callers of gcDrain control whether it flushes scan work
credit to gcController.bgScanCredit by passing a value other than -1
for the flush threshold. Shortly we're going to make this always flush
scan work to gcController.scanWork and optionally also flush scan work
to gcController.bgScanCredit. This will be much easier if the flush
threshold is simply a constant (which it is in practice) and callers
merely control whether or not the flush includes the background
credit. Hence, replace the flush threshold argument with a flag.

Change-Id: Ia27db17de8a3f1e462a5d7137d4b5dc72f99a04e
Reviewed-on: https://go-review.googlesource.com/15406Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      c18b163c
    • Austin Clements's avatar
      runtime: consolidate gcDrain and gcDrainUntilPreempt · 9b3cdaf0
      Austin Clements authored 
      These functions were nearly identical. Consolidate them by adding a
flags argument. In addition to cleaning up this code, this makes
further changes that affect both functions easier.

Change-Id: I6ec5c947603bbbd3ff4040113b2fbc240e99745f
Reviewed-on: https://go-review.googlesource.com/15405Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      9b3cdaf0
    • Austin Clements's avatar
      runtime: explain why continuous assist revising is necessary · 39ed6822
      Austin Clements authored 
      Change-Id: I950af8d80433b3ae8a1da0aa7a8d2d0b295dd313
Reviewed-on: https://go-review.googlesource.com/15404Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      39ed6822
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7