We need to stop documenting the heap dump in a wiki and document it in the main go repo in the same commit where the format changes.

Ideally with, say, tests. And ideally end-to-end tests writing then reading the heap dump that would break if the heapdump format changes. (which empirically it does, regularly)

/cc @randall77

@matloob

CL https://golang.org/cl/21647 mentions this issue.

Undocumented but also nearly unusable. Leave both for Go 1.9.

Bumping to 1.10. Most likely we're going to rip out the heap dump format and replace it with @randall77's core dump reader, at which point this will become obsolete, but that's not going to happen until 1.10.

I am currently reading through the heap dump that go 1.20 writes the same way a debugger would by traversing the stack variables using dwarf info, follow pointers to the heap and continue walking using dwarf info. That works pretty well. I can even identify interface types by reading the binaries rodata + noptrdata to access rtype instances pointed to in those interfaces. I can then map rtype back to a pkg/type name and look it up in the dwarf types. This allows me to resolve the interface and recurse into the allocated values on the heap.

Some issues that i currently see:

• funcval do have dwarf data, but i dont see the funcvals dwarf type of a closure/functype referenced anywhere.
• usage of unsafe.Pointer (e.g. in sync.Pool) translates basically into a *void pointer. no dwarf data there. With prior knowledge I could handle special cases (like sync.Pool - it stores interfaces).

In a real world http service this helps me identifying around 30-40% of my heap objects or 50% of the heap data. not great, not too bad either.