Should definitely do (1) first.
(2) can happen later if needed.

I can't reproduce this after https://go-review.googlesource.com/2349 was applied.

However, I think we're seeing this issue in production on one of the services at my job. I'll report back after I've grabbed some data.

I just tried @dvyukov's test program on latest master and it runs in 1.3s and has the same profile with and without the "y = ..." line.

@DanielMorsing, are you still seeing this issue?

No, the issue in production turned out to be a case of some spurious allocations being made by application code.

I still think we're doing excessive sweeping, but it runs concurrently with mutator code, so the effects aren't as apparent. Should be easier to figure out what's happening after https://go-review.googlesource.com/#/c/9506/ was applied.

@aclements I guess you now need a different program to trigger this issue. Probably now GC collects the large span before the program allocates sufficient amount of small spans.

No repro program, so no issue.

Such approach to bug handling is kind of discouraging.
Catch a new repro program:

package main

import (
    "fmt"
    "os"
    "runtime"
    "time"
)

var z []byte
var x [][]byte

func main() {
    t0 := time.Now()
    if len(os.Args) > 1 {
        for i := 0; i < 1<<20; i++ {
            x = append(x, make([]byte, 1<<13))
        }
        x = nil
        runtime.GC()
    }
    fmt.Println(time.Since(t0))
    t0 = time.Now()
    for i := 0; i < 1e5; i++ {
        z = make([]byte, 1<<13)
    }
    fmt.Println(time.Since(t0))
}

$ ./test
2.245µs
582.776723ms

$ ./test 1
3.470712076s
19.764293403s

That's 34x slowdown.

This didn't happen in time.

Missed again.

Just to expand on the original report a bit, when the heap is full of dead spans like in this test case, half of the time in sweepone is spent just incrementing the sweepidx and the other half is spent in cache misses just to check the span state (and determine that it's dead). This particular test amplifies this because it drives so many GC cycles in the second phase and, since the number of spans never goes down from the peak, between the closely spaced GC cycles in the second phase, sweeping has to sweep all of the dead spans.

This isn't going to happen for 1.7, but my hope for 1.8 is that we can eliminate proportional sweeping entirely, which will fix this problem at its root.

ping @aclements, is this still going to make 1.8?

CL https://golang.org/cl/30536 mentions this issue.

CL https://golang.org/cl/30535 mentions this issue.