[go-nuts] Re: Why does a "concurrent" Go GC phase appear to be stop-the-world?

I just wrote up our investigation in this blog post: https://blog.pusher.com/golangs-real-time-gc-in-theory-and-practice/ It includes an animation of the GC algorithm that my colleague James Fisher made. I think this could be valuable as a standalone resource. If any of you have any feedback,

[go-nuts] Re: Why does a "concurrent" Go GC phase appear to be stop-the-world?

Thanks for confirming that CL 23540 has reduced STW delays. On Friday, 28 October 2016 03:52:29 UTC+11, Will Sewell wrote: > > Are you referring to https://go-review.googlesource.com/#/c/23540/ or > https://github.com/golang/go/issues/16528? If it's the former, then yes I > have tried the

[go-nuts] Re: Why does a "concurrent" Go GC phase appear to be stop-the-world?

Are you referring to https://go-review.googlesource.com/#/c/23540/ or https://github.com/golang/go/issues/16528? If it's the former, then yes I have tried the benchmark with the HEAD version on master of the compiler, and it did bring the pause down to ~7.7ms. I was under the impression the

[go-nuts] Re: Why does a "concurrent" Go GC phase appear to be stop-the-world?

Thanks for the information. I think it could well be caused by that. Below is the screenshot of one of the periods of time where the mutator is blocked.

[go-nuts] Re: Why does a "concurrent" Go GC phase appear to be stop-the-world?

Yes, this sounds like https://golang.org/issue/16528. During the concurrent mark phase (the "27 [ms]" of "0.008+27+0.072 ms clock"), both your code and the garbage collector are running. The program is allowed to use four OS threads ("4 P"), which might be executing your code in your

[go-nuts] Re: Why does a "concurrent" Go GC phase appear to be stop-the-world?

Interesting, that does sound like it could be the cause. I just tried running the same benchmark on master (692df217ca21b6df8e4dc65538fcc90733e8900e), and I get the following results: gc 1 @0.004s 3%: 0.009+0.41+0.049 ms clock, 0.036+0.11/0.36/0.12+0.19 ms cpu, 4->4->3 MB, 5 MB goal, 4 P gc 2

[go-nuts] Re: Why does a "concurrent" Go GC phase appear to be stop-the-world?

Yes, this sounds a lot like https://golang.org/issue/16293, where goroutines that allocate memory while the garbage collector is running can end up stalled for nearly the entire GC cycle, in programs where a large amount of the memory is in a single allocation. For the program you've shared,

[go-nuts] Re: Why does a "concurrent" Go GC phase appear to be stop-the-world?

This is likely 23540 . On Wednesday, October 19, 2016 at 8:32:18 AM UTC-4, Will Sewell wrote: > > Hey, I previously posted this on StackOverflow, but I was told this > mailing list would be a better forum for discussion. > > I am attempting to