Also, I don't think it's the Stack. If you replace Alloc with HeapAlloc... it's all there.
On Sunday, April 18, 2021 at 12:33:20 PM UTC-5 Trig wrote: > Correct... the example using time.Sleep didn't run on the playground. The > original post I made, I provided the link with just a goroutine with an > empty function. > > At least you were able to reproduce what I'm inquiring about. I'll look > further into this, but surely unused and finished goroutines don't leave > stuff laying around like that. > > On Sunday, April 18, 2021 at 3:47:10 AM UTC-5 Brian Candler wrote: > >> What do you mean by "It won't work on the playground"? It runs for me. >> Are you saying you get different results when running locally? If so, what >> version of go are you running locally, on what platform, and what do you >> see? >> >> Or are you saying the problem is really with something like this? >> https://play.golang.org/p/Q91Qd-DvvKx >> >> That indeed fails to run in the playground - it exits with signal 9 >> (128+9=137) >> >> Running locally with go 1.16.3 under macOS (Intel) I see: >> >> Allocs before: 82696 >> Allocs while running: 51496728 >> Allocs after: 40384112 >> Allocs after: 40384112 >> Allocs after: 40384112 >> Allocs after: 40384112 >> Allocs after: 40384112 >> >> That is 40MB that apparently isn't reclaimed, but it does get reused if >> you run more goroutines: >> https://play.golang.org/p/YcMTlLYxXAP >> >> I don't know why that is. It's about 400 bytes per goroutine. Stack >> perhaps? >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/10623387-ee28-4b69-b393-6b64d6e48366n%40googlegroups.com.
