{"push_id":821970687,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"89c341c5e969b571a9475b263b237a8a25efd76b","before":"9e77c898688529c4d73ad8912d47b20e679a2cfa","commits":[{"sha":"89c341c5e969b571a9475b263b237a8a25efd76b","author":{"email":"7ea35d812706d9213868749011af1ed4fa2f6aa0@google.com","name":"Austin Clements"},"message":"runtime: directly track GC assist balance\n\nCurrently we track the per-G GC assist balance as two monotonically\nincreasing values: the bytes allocated by the G this cycle (gcalloc)\nand the scan work performed by the G this cycle (gcscanwork). The\nassist balance is hence assistRatio*gcalloc - gcscanwork.\n\nThis works, but has two important downsides:\n\n1) It requires floating-point math to figure out if a G is in debt or\n   not. This makes it inappropriate to check for assist debt in the\n   hot path of mallocgc, so we only do this when a G allocates a new\n   span. As a result, Gs can operate \"in the red\", leading to\n   under-assist and extended GC cycle length.\n\n2) Revising the assist ratio during a GC cycle can lead to an \"assist\n   burst\". If you think of plotting the scan work performed versus\n   heaps size, the assist ratio controls the slope of this line.\n   However, in the current system, the target line always passes\n   through 0 at the heap size that triggered GC, so if the runtime\n   increases the assist ratio, there has to be a potentially large\n   assist to jump from the current amount of scan work up to the new\n   target scan work for the current heap size.\n\nThis commit replaces this approach with directly tracking the GC\nassist balance in terms of allocation credit bytes. Allocating N bytes\nsimply decreases this by N and assisting raises it by the amount of\nscan work performed divided by the assist ratio (to get back to\nbytes).\n\nThis will make it cheap to figure out if a G is in debt, which will\nlet us efficiently check if an assist is necessary *before* performing\nan allocation and hence keep Gs \"in the black\".\n\nThis also fixes assist bursts because the assist ratio is now in terms\nof *remaining* work, rather than work from the beginning of the GC\ncycle. Hence, the plot of scan work versus heap size becomes\ncontinuous: we can revise the slope, but this slope always starts from\nwhere we are right now, rather than where we were at the beginning of\nthe cycle.\n\nChange-Id: Ia821c5f07f8a433e8da7f195b52adfedd58bdf2c\nReviewed-on: https://go-review.googlesource.com/15408\nReviewed-by: Rick Hudson <rlh@golang.org>","distinct":true,"url":"https://api.github.com/repos/golang/go/commits/89c341c5e969b571a9475b263b237a8a25efd76b"}]}