Why runtime force gc every 2 minutes?

2,493 views
Skip to first unread message

Kurnia D Win

unread,
Dec 7, 2021, 9:20:23 PM12/7/21
to golang-nuts
Why runtime force gc every 2 minutes?, https://github.com/golang/go/blob/016e6ebb4264f4b46e505bb404953cdb410f63f2/src/runtime/proc.go#L5226

AFAIK gc will be triggered when user try to allocate memory (the mallocgc func)

and if user want to force gc every 2 minutes, they can create their own goroutine to call runtime.GC() every 2 minute

Kurtis Rader

unread,
Dec 7, 2021, 9:32:39 PM12/7/21
to Kurnia D Win, golang-nuts
On Tue, Dec 7, 2021 at 6:20 PM Kurnia D Win <kurnia...@gmail.com> wrote:
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

Kurnia D Win

unread,
Dec 13, 2021, 10:28:26 PM12/13/21
to golang-nuts
> 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.


> 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?

Brian Candler

unread,
Dec 14, 2021, 3:27:18 AM12/14/21
to golang-nuts
On Tuesday, 14 December 2021 at 03:28:26 UTC kurnia...@gmail.com wrote:
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

Let's say it wastes, say, 10 milliseconds every 2 minutes - and it doesn't even stop the program for that time but runs GC in a separate thread. Is that a big deal, in order to give reasonable behaviour across a wide range of programs?

If you need such fine low-level control, then maybe a different language like Rust (or even C) might be better for your application.

Kurnia D Win

unread,
Dec 14, 2021, 4:13:05 AM12/14/21
to golang-nuts
okay, thanks for the explanation, 
suggesting me to change language to rust/c is not answering my curiosity
I ask it because I'm trying to learn the runtime, and the "why" behind some decision that already made
for now, I will just follow it blindly, because the go developers already made that decision

thank you

Kurnia D Win

unread,
Dec 14, 2021, 4:14:14 AM12/14/21
to golang-nuts
oh, maybe they just trying random configuration (1min, 5min, or something else)
and 2min is the best result

peterGo

unread,
Dec 14, 2021, 9:05:09 AM12/14/21
to golang-nuts
There is no right answer to your question. Optimiation is often a balancing act between competing goals, for example, cpu vs menory, speed vs memory safety, different workloads, avoiding worst cases, and so on.

Here's a peek at the problem in 2018: https://go.dev/blog/ismmkeynote.Since then, there have been other refinements. In 2018,, a primary goal was to reduce gc latency. Once you fix that, other issues come to the fore.

Peter

peterGo

unread,
Dec 14, 2021, 9:07:34 AM12/14/21
to golang-nuts
Getting to Go: The Journey of Go's Garbage Collector
Rick Hudson
12 July 2018

https://go.dev/blog/ismmkeynote

Peter
Reply all
Reply to author
Forward
0 new messages