@chjara So it seems that the leak generates some process-associated objects that are actually destroyed with the process, but not destroyed when w/e in userspace requests them to be.

This isn't as weird as it might sound. For example, if vma (virtual memory area) coalescing (i.e. stitching together two adjacent mappings that happen to be equivalent to one mapping -- because they point at appropriately distant offsets in the same file) didn't work, the way Golang uses heap might cause kernel to keep creating more and more vmas, until they all get destroyed when the process exits.

Try looking at /proc/slabinfo and compare contents when the leak has leaked lots of memory and when it hasn't. (Slab is an allocator in kernel for objects of known and fixed sizes: if the leak is in one of those classes, then you can narrow down _what_ is leaking.) If you can find the leak there, it should be much easier to debug.