On Fri, Mar 6, 2020 at 5:21 PM Christophe Meessen < christophe.mees...@gmail.com> wrote:
> > However, it never gets back to the low level it had initially. Initial > lowest Alloc is 146520. It then grows steadily up to 163040. Then suddenly > drops to 156896, and grows slowly again to 163520. Then drops suddenly to > 157376. Etc. > So memory is indeed a little bit partially reclaimed from time to time. So > the GC kind of works, but the GC() function doesn’t behave as I was > expectiong. > > Small fluctuations like these are somewhat expected. In a multi-core environment, you often want to cache processor-locally. Many malloc implementations would show the same behavior nowadays. However, what is more likely here is that you are looking at different snapshots when the sweep phase is being run. Once we have marked all live data in the GC, we initiate the sweep phase to reclaim the unmarked data. But this happens incrementally while our program is running. Thus we can probably expect the numbers to fluctuate a small bit. Note that while your program only allows one OS thread, the GC will happily use all your available cores for speeding up the the GC phase. So you are also looking at non-determinism in a concurrent environment. You need to rely on different methods if you want to detect for memory leaks in programs. The package "runtime/pprof" contains ways to get a memory profile of the program, including allocations at call sites and so on. I would probably use these tools to hunt for eventual memory leaks in programs. -- 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/CAGrdgiU2Efc%3DLnH%3DTVHuUytoQnR2COSZYe8Y3PS2zdSZ-41Ajg%40mail.gmail.com.
