When you say that the program holds ~1.3GB of memory, how are you measuring that?

Have you tried calling https://golang.org/pkg/runtime/debug/#FreeOSMemory ?

I can reproduce this on Linux with GOMAXPROCS=1 on go1.6.

What is happening is that you are spawning 600,000 goroutines. Depending on how the scheduler behaves, if all are spawned before any finish, you'll use up to ~1.3GB (~2K per goroutine). If goroutines finish faster than you spawn them, then memory usage will be quite low. That's why GOMAXPROCS matters, and why the GC at point A affects things.

When you get to the sleep, Go is not using the ~1.3GB anymore. But it hasn't given that memory back to the OS yet. Wait 5 minutes or call debug.FreeOSMemory.

I believe this is the expected behavior and that this issue should be closed.

Thank you for your responses! I tried FreeOSMemory (btw small nit in the code I posted, I should wrap fmt.Println with a function), I waited 20 minutes, previously I also made system swapping. Nothing changed. I understand that Go likes to stash memory for later but how this pprof output can be explained, why it reports 168MB in runtime.malg 384B bucket (/debug/pprof/goroutine shows only 6 goroutines)?

The allocations from malg (the goroutine allocator) are for goroutine descriptors. Goroutine descriptors are never freed, we keep a free list of them around. That is issue #9869.

I'm going to close this as a dupe of #9869; that does sound like this problem.