looks very promising, one of the biggest issue in golang for me is profiling and constant memory leaks/pressure. Not sure if there is an alternative of what people use now
How are you getting "constant memory leaks" in a GC'd language?
[deleted]
Go has added Valgrind support
21–30 of 157 posts
Re: Go has added Valgrind support
#22This is only useful for cgo correct?
I presume it is also useful if you are using the unsafe APIs as well to mess with pointers and do raw memory reads.
Re: Go has added Valgrind support
#23It only works if every package tests with it. Otherwise the relevant warnings get swamped by a huge amount by irrelevant warnings. This is why running Valgrind on Python code does not work.
If that were true it would also apply to C and C++. I have used Valgrind with Python + Boost C++ hybrid programs and it worked fine after spending an hour making a suppressions file.
> it worked fine after spending an hour making a suppressions file.
So you are confirming the problem, but treating it as if ignoring it is the solution for all?
Re: Go has added Valgrind support
#24Earlier quoted context omitted.
How are you getting "constant memory leaks" in a GC'd language?
Golang has a feature that I love in general but that makes it very easy to keep unintended allocations around. If you have a struct with a simple int field, and you store that somewhere as an *int, the entire struct and anything it points to will be kept alive. This is super useful for short-lived pointers, and super dangerous for long-lived pointers. Most other widely used GCed languages don’t allow the use of arbit…
> If you have a struct with a simple int field, and you store that somewhere as an *int, the entire struct and anything it points to will be kept alive.
While Go allows interior pointers, I don't think what you say is true. runtime.KeepAlive was added exactly to prevent GC from collecting the struct when only a field pointer is stored. Take a look at this blog post, for example: https://victoriametrics.com/blog/go-runtime-finalizer-keepal...
Re: Go has added Valgrind support
#25Earlier quoted context omitted.
How are you getting "constant memory leaks" in a GC'd language?
There’s ways, GC isn’t perfect . A common one I see fairly often is opening a big file, creating a “new slice” on a subset of the file and then using the “new slice” and expecting the old large object to be dropped. Except, the “new slice” is just a reference into the larger slice, so its never marked unused.
Interesting, I always thought of slices as stand-alone, I wonder if its the same in Python?
Re: Go has added Valgrind support
#26looks very promising, one of the biggest issue in golang for me is profiling and constant memory leaks/pressure. Not sure if there is an alternative of what people use now
How are you getting "constant memory leaks" in a GC'd language?
A GC only deallocates unreferenced memory, if you keep unused references, that's a leak the GC won't catch, as it has no way to know that you won't need it later.
It can happen when your variables have too long a lifespan, or when you have a cache where the entries are not properly evicted.
Re: Go has added Valgrind support
#27Earlier quoted context omitted.
There’s ways, GC isn’t perfect . A common one I see fairly often is opening a big file, creating a “new slice” on a subset of the file and then using the “new slice” and expecting the old large object to be dropped. Except, the “new slice” is just a reference into the larger slice, so its never marked unused.
Interesting, I always thought of slices as stand-alone, I wonder if its the same in Python?
No, python slice syntax on lists returns a new list. Of course, the slice syntax on your own classes can do just about anything using operator overloading.
Re: Go has added Valgrind support
#28Re: Go has added Valgrind support
#29Earlier quoted context omitted.
If that were true it would also apply to C and C++. I have used Valgrind with Python + Boost C++ hybrid programs and it worked fine after spending an hour making a suppressions file.
> it worked fine after spending an hour making a suppressions file. So you are confirming the problem, but treating it as if ignoring it is the solution for all?
it's a rejection of the thesis that it "does not work".
It does, but it requires investing into a suppression file.
Re: Go has added Valgrind support
#30Earlier quoted context omitted.
How are you getting "constant memory leaks" in a GC'd language?
A GC only deallocates unreferenced memory, if you keep unused references, that's a leak the GC won't catch, as it has no way to know that you won't need it later. It can happen when your variables have too long a lifespan, or when you have a cache where the entries are not properly evicted.
But how would Valgrind know more than the GC? Of course a program in a GCed language can leak memory, but it’s not clear to me how Valgrind would detect the kinds of memory leaks that you can create in pure Go code (without calling into C or using unsafe functions to allocate memory directly).