Skip to content

G
go
Switch branch/tag
  1. 16 Oct, 2015 5 commits
  3. 15 Oct, 2015 6 commits
  5. 14 Oct, 2015 9 commits
  7. 13 Oct, 2015 5 commits
  9. 12 Oct, 2015 4 commits
  11. 11 Oct, 2015 2 commits
  13. 10 Oct, 2015 4 commits
  15. 09 Oct, 2015 5 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7