I have seen this being used in other code, and we are doing this ourselves, but I am currently wondering if there is any drawback to this.
The documentation for runtime.GC() says that it blocks the caller, and that seems to suggest it’s easy to work around it by just saying go runtime.GC() instead. Is there any known downside to triggering the garbage collector in a separate goroutine, or is that “safe” to do? (It’s obviously semantically correct, but is there for example a known performance penalty, or some other issue?)
Running runtime.GC in another goroutine might still block the current goroutine if the runtime needs to perform a “stop the world” collection, but it should be only a few tens or hundreds of microseconds.
Why are you calling runtime.GC at all? If there’s a performance reason, I suspect you have benchmarks where you could test the differences in performance between go runtime.GC() and runtime.GC().
Thanks a lot for your answer. It’s for an application that uses a large amount of RAM (several hundreds of GB), and that runs for several hours, so doing these kinds of benchmarks is very costly and time-consuming. I’m looking for answers along the lines of “that’s obviously wrong” or “that’s obviously fine,” for reasons that I might be missing. If there is no obvious answer, then of course we will have to dig into the details ourselves…
I understand now. Unfortunately, I don’t have the experience to provide a good answer. I’ll ask that if you find the answer, that you post it back here. It could help others that find this post and answer in the future. Good luck! If you have a problem with a smaller scope perhaps the community here could give you better advice!
