cmd/internal/obj: write package path at compile time if possible
Currently, when the compiler emits a symbol name in the object file, it uses "". for the package path of the package being compiled. This is then expanded in the linker to the actual package path. With CL 173938, it does not need an allocation if the symbol name does not need expansion. In many cases, the compiler actually knows the package path (through the -p flag), so we could just write it out in compile time, without fixing it up in the linker. This reduces allocations in the linker. In case that the package path is not known (compiler's -p flag is missing, or the object file is generated by the assembler), the linker still does the expansion. This reduces ~100MB allocations (~10% inuse_space) in linking k8s.io/kubernetes/cmd/kube-apiserver on Linux/AMD64. Also makes the linker a little faster: linking cmd/go on Linux/AMD64: Real 1.13 ± 1% 1.11 ± 1% -2.13% (p=0.000 n=10+10) User 1.17 ± 3% 1.14 ± 5% -3.14% (p=0.003 n=10+10) Sys 0.34 ±15% 0.34 ±15% ~ (p=0.986 n=10+10) The caveat is that the object files get slightly bigger. On Linux/AMD64, runtime.a gets 2.1% bigger, cmd/compile/internal/ssa (which has a longer import path) gets 2.8% bigger. This reveals that when building an unnamed plugin (e.g. go build -buildmode=plugin x.go), the go command passes different package paths to the compiler and to the linker. Before this CL there seems nothing obviously broken, but given that the compiler already emits the package's import path in various places (e.g. debug info), I guess it is possible that this leads to some unexpected behavior. Now that the compiler writes the package path in more places, this disagreement actually leads to unresolved symbols. Adjust the go command to use the same package path for both compiling and linking. Change-Id: I19f08981f51db577871c906e08d9e0fd588a2dd8 Reviewed-on: https://go-review.googlesource.com/c/go/+/174657Reviewed-by: Austin Clements <austin@google.com>
Showing
Please register or sign in to comment