test: force heap profile update in heapsampling.go test

The heapsampling.go test occasionally fails on some architectures
because it finds zero heap samples in main.alloc. This happens because
the byte and object counts are only updated at a GC. Hence, if a GC
happens part way through allocInterleaved, but then doesn't happen
after we start calling main.alloc, checkAllocations will see buckets
for the lines in main.alloc (which are created eagerly), but the
object and byte counts will be zero.

Fix this by forcing a GC to update the profile before we collect it.

Fixes #13098.

Change-Id: Ia7a9918eea6399307f10499dd7abefd4f6d13cf6
Reviewed-on: https://go-review.googlesource.com/16846
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

test/heapsampling.go

@@ -25,8 +25,6 @@ var a64k *[64 * 1024]byte
 // vary for run to run. This test only checks that the resulting
 // values appear reasonable.
 func main() {
-	return // TODO: fix this flaky test; golang.org/issue/13098
-
 	const countInterleaved = 10000
 	allocInterleaved(countInterleaved)
 	checkAllocations(getMemProfileRecords(), "main.allocInterleaved", countInterleaved, []int64{256 * 1024, 1024, 256 * 1024, 512, 256 * 1024, 256})
@@ -93,6 +91,9 @@ func checkValue(fname string, ln int, name string, want, got int64) {
 }
 
 func getMemProfileRecords() []runtime.MemProfileRecord {
+	// Force the runtime to update the object and byte counts.
+	runtime.GC()
+
 	// Find out how many records there are (MemProfile(nil, true)),
 	// allocate that many records, and get the data.
 	// There's a race—more records might be added between