net/http/httptrace: uses reflect.Value.Call, forces linker's deadcode to be conservative

[bradfitz]

net/http/httptrace uses reflect.Value.Call:

https://github.com/golang/go/blob/release-branch.go1.14/src/net/http/httptrace/trace.go#L201

Its use anywhere in a program forces the linker's deadcode pass to go into its conservative mode when deciding whether to preserve otherwise-unused exported methods.

Because net/http depends on httptrace, any net/http program is potentially larger than it needs to be, even if the caller program doesn't use httptrace. That then makes binaries bigger (138 KiB larger in one program here)

(People who like this bug might also like #38450)

We should probably rewrite (or auto-generate?) httptrace to not use reflect.Value.Call.

[bradfitz]

I think this was fixed by https://go-review.googlesource.com/c/go/+/228792

But that might get reverted due to #38515, depending on how it gets fixed.

https://go-review.googlesource.com/c/go/+/228878 adds tests that reflect.Value.Call stops making the linker do this, though, so this bug can likely be closed once CL 228878 is in and #38515 is fixed.

[gopherbot]

Change https://golang.org/cl/228878 mentions this issue: cmd/link: add a test that reflect.Value.Call does not bring methods live

[bradfitz]

Okay, we can close this now.

It's also not as bad as I originally thought: a program that imported net/http but didn't use httptrace.WithClientTrace didn't end up going into conservative reflectSeen mode.

But with the latest toolchain changes (notably https://go-review.googlesource.com/c/go/+/228792), even using WithClientTrace shouldn't trigger the linker's reflectSeen, as it doesn't do any method lookups.