by fsmv on 7/22/2025, 5:52:53 PM
by felixge on 7/22/2025, 6:34:08 PM
Hacking into the Go runtime with eBPF is definitely fun.
But for a more long term solution in terms of reliability and overhead, it might be worth raising this as a feature request for the Go runtime itself. Type information could be provided via pprof labels on the allocation profiles.
by jasonthorsness on 7/22/2025, 3:33:52 PM
Interesting... usually you can guess at what is being allocated from the function doing the allocation, but in this case the author was interested in types that are allocated from a ton of locations (spoiler alert: it was strings). Nice use of bpftrace to hack out the information required.
by osigurdson on 7/22/2025, 6:29:54 PM
>> func (thing Thing) String() string { if thing == nil { return nil } str = ... return &str }
It seems like the "..." of str = ... is the interesting part.
by 90s_dev on 7/22/2025, 5:57:57 PM
I forgot to ask, that day that the Go team did an AMA here: did AI have any influence or sway or advice etc in choosing Go over other solutions?
It is very difficult to avoid putting strings on the heap in go. I used the built in escape analysis tools and made sure I only use a constant amount of memory in the loop in my short https://github.com/fsmv/in.go progress bar program.
The biggest problem is any string you pass as an argument to the fmt functions is moved onto the heap because interface{} is always counted as escaped from the stack (https://github.com/golang/go/issues/8618).