Memory improvements to loadRawSpec

[paulcacheux]

This PR contains memory usage (and small cpu) improvements to lawRawSpec through:

• precomputing the amount of required fixups when building the type graph
• guess-timating the amount of types when reading the btf types reducing the amount of buffer reallocation

Benchmark:

>>> sudo go test -run=XXX -bench=BenchmarkParseVmlinux ./internal/btf

Before (master branch):

goos: linux
goarch: amd64
pkg: github.com/cilium/ebpf/internal/btf
cpu: Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz
BenchmarkParseVmlinux-4   	       9	 118640220 ns/op	96579569 B/op	  786353 allocs/op
PASS
ok  	github.com/cilium/ebpf/internal/btf	2.049s

After (updated after review):

goos: linux
goarch: amd64
pkg: github.com/cilium/ebpf/internal/btf
cpu: Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz
BenchmarkParseVmlinux-4   	      14	  76856666 ns/op	53361862 B/op	  574838 allocs/op
PASS
ok  	github.com/cilium/ebpf/internal/btf	2.001s

Happy to discuss future paths of improvements

[florianl]

maybe a personal preference:
I prefer the use of reflect.StringHeader{} over this approach. If bytes contains malicious data and Len in reflect.StringHeader{} is not set, it can result in unintended side effects when using the string.
Both approaches avoid additional allocations so this is an improvement memory wise.

[lmb]

I gave your suggestion a quick whirl:

func unsafeBytesToString(bytes []byte) string {
	if len(bytes) == 0 {
		return ""
	}

	sh := &reflect.StringHeader{
		Data: uintptr(unsafe.Pointer(&bytes[0])),
		Len:  len(bytes),
	}

	str := *(*string)(unsafe.Pointer(sh))
	runtime.KeepAlive(bytes)
	return str
}

Seems to work, though some linter complains about this being a possible misuse of StringHeader. What do you mean with bytes containing malicious data though?

[lmb]

Another thing I'm trying to figure out: this trick effectively pins the entire string table in memory. So while we allocate less overall, the peak memory usage after parsing might be higher. I'm thinking of a case where a user parses vmlinux, gets out some type they are interested in, and afterwards discards the Spec. The single retained type would lock the string table into memory.

[paulcacheux]

This is true sadly, and it may not be acceptable

[lmb]

It's cool to see these improvements, thanks a lot! I'll do a full review in a bit, but how about merging the non-unsafe commits? I have an idea how we might be able to cut down allocations without pinning the memory, but it needs a bit of experimenting.

[lmb]

Looks good, I have some small remarks. Could you clean up the commit history a bit?

[lmb]

Thanks!