11–20 of 157 posts
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?
do you think they will enable Valgrind if there's no leaks?
[flagged]
[flagged]
That's already possible and documented[1]. I don't understand if you're sarcastic though, what's wrong with GDB? I use it in vim :termdebug and I wish all languages had native support for it.
[flagged]
Nothing wrong with adding tried and tested tools later if people want them.
Did you have a need for Valgrind in Go that wasn't served by any other tools until now?
It 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.
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?
Most other widely used GCed languages don’t allow the use of arbitrary interior pointers (though most GCs can actually handle them at the register level).
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?
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.
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?
- you can create deadlocks
- spawn goroutines while not making sure they have proper exit criteria
- use slices of large objects in memory and pass them around (e.g. read files in a loop and pass only slice from whole buffer)
- and so onlooks 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
Ideally, they would have learnt from other languages, and offered explicit control over what goes into the stack instead of relying into escape analysis alone. As it is, the only way to currently handle that is with " -gcflags -m=3" or using something like VSCode Go plugin, via "ui.codelenses" and "ui.diagnostic.annotations" configurations.
> Instead of adding the Valgrind headers to the tree, and using cgo to call the various Valgrind client request macros, we just add an assembly function which emits the necessary instructions to trigger client requests. Love that they have taken this route, this is the way bootstraped toolchains should be, minimal building blocks and everything else on the language itself.