2 Commits (57856fc0d5cbffdb81d28b0dd94e5ab2110fd58c)

Author	SHA1	Message	Date
Will Norris	71029cea2d	all: update copyright and license headers ... This updates all source files to use a new standard header for copyright and license declaration. Notably, copyright no longer includes a date, and we now use the standard SPDX-License-Identifier header. This commit was done almost entirely mechanically with perl, and then some minimal manual fixes. Updates #6865 Signed-off-by: Will Norris <will@tailscale.com>	2 years ago
Josh Bleecher Snyder	4bb2c6980d	util/testingutil: new package with MinAllocsPerRun ... testing.AllocsPerRun measures the total allocations performed by the entire program while repeatedly executing a function f. If some unrelated part of the rest of the program happens to allocate a lot during that period, you end up with a test failure. Ideally, the rest of the program would be silent while testing.AllocsPerRun executes. Realistically, that is often unachievable. AllocsPerRun attempts to mitigate this by setting GOMAXPROCS to 1, but that doesn't prevent other code from running; it only makes it less likely. You can also mitigate this by passing a large iteration count to AllocsPerRun, but that is unreliable and needlessly expensive. Unlike most of package testing, AllocsPerRun doesn't use any toolchain magic, so we can just write a replacement. One wild idea is to change how we count mallocs. Instead of using runtime.MemStats, turn on memory profiling with a memprofilerate of 1. Discard all samples from the profile whose stack does not contain testing.AllocsPerRun. Count the remaining samples to determine the number of mallocs. That's fun, but overkill. Instead, this change adds a simple API that attempts to get f to run at least once with a target number of allocations. This is useful when you know that f should allocate consistently. We can then assume that any iterations with too many allocations are probably due to one-time costs or background noise. This suits most uses of AllocsPerRun. Ratcheting tests tend to be significantly less flaky, because they are biased towards success. They can also be faster, because they can exit early, once success has been reached. Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com>	3 years ago