> It's a heuristic. The Go developers probably observed that starting a GC approximately every two minutes was a reasonable trade-off between the overhead of a GC cycle and memory used.
is there any stat/data on this decision? and what will happen if you make it 1 minute or 5 minutes, average CPU usage will go up? or average memory usage will go up? > Not true. Nope, it's true, but yes, not every malloc will trigger GC, https://github.com/golang/go/blob/1afa432ab93aa9adb2e0f04b6c15eb654762d652/src/runtime/malloc.go#L1203 > Requiring that level of control is generally anathema to a GC language. The language runtime should provide reasonable behavior for the vast majority of its users without requiring them to manually jump through such hoops. What you're suggesting is equivalent to saying that Go should require its users to manually manage its memory; such as with `C`. the problem with it, when you have a large live heap but with efficient code (most of the hot code is zero alloc), the runtime will be wasting CPU time every 2 minutes just to find out that there is no garbage to collect I think without forcing GC every 2 minutes the app will work fine, that is why I'm curious what kind of trade-off we make here? On Wednesday, December 8, 2021 at 9:32:39 AM UTC+7 kra...@skepticism.us wrote: > On Tue, Dec 7, 2021 at 6:20 PM Kurnia D Win <kurnia...@gmail.com> wrote: > >> Why runtime force gc every 2 minutes?, >> https://github.com/golang/go/blob/016e6ebb4264f4b46e505bb404953cdb410f63f2/src/runtime/proc.go#L5226 >> > > It's a heuristic. The Go developers probably observed that starting a GC > approximately every two minutes was a reasonable trade-off between the > overhead of a GC cycle and memory used. > > >> AFAIK gc will be triggered when user try to allocate memory (the mallocgc >> func) >> > > Not true. > > >> and if user want to force gc every 2 minutes, they can create their own >> goroutine to call runtime.GC() every 2 minute >> >> Requiring that level of control is generally anathema to a GC language. > The language runtime should provide reasonable behavior for the vast > majority of its users without requiring them to manually jump through such > hoops. What you're suggesting is equivalent to saying that Go should > require its users to manually manage its memory; such as with `C`. > > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank > -- 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/635b94bb-35a1-4ece-bfa9-a7de9146765cn%40googlegroups.com.
