go/src/cmd/compile/internal/gc/util.go

104 lines
2.2 KiB
Go
Raw Normal View History

// Copyright 2015 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package gc
import (
"os"
"runtime"
"runtime/pprof"
)
cmd/compile,link: generate PC-value tables with inlining information In order to generate accurate tracebacks, the runtime needs to know the inlined call stack for a given PC. This creates two tables per function for this purpose. The first table is the inlining tree (stored in the function's funcdata), which has a node containing the file, line, and function name for every inlined call. The second table is a PC-value table that maps each PC to a node in the inlining tree (or -1 if the PC is not the result of inlining). To give the appearance that inlining hasn't happened, the runtime also needs the original source position information of inlined AST nodes. Previously the compiler plastered over the line numbers of inlined AST nodes with the line number of the call. This meant that the PC-line table mapped each PC to line number of the outermost call in its inlined call stack, with no way to access the innermost line number. Now the compiler retains line numbers of inlined AST nodes and writes the innermost source position information to the PC-line and PC-file tables. Some tools and tests expect to see outermost line numbers, so we provide the OutermostLine function for displaying line info. To keep track of the inlined call stack for an AST node, we extend the src.PosBase type with an index into a global inlining tree. Every time the compiler inlines a call, it creates a node in the global inlining tree for the call, and writes its index to the PosBase of every inlined AST node. The parent of this node is the inlining tree index of the call. -1 signifies no parent. For each function, the compiler creates a local inlining tree and a PC-value table mapping each PC to an index in the local tree. These are written to an object file, which is read by the linker. The linker re-encodes these tables compactly by deduplicating function names and file names. This change increases the size of binaries by 4-5%. For example, this is how the go1 benchmark binary is impacted by this change: section old bytes new bytes delta .text 3.49M ± 0% 3.49M ± 0% +0.06% .rodata 1.12M ± 0% 1.21M ± 0% +8.21% .gopclntab 1.50M ± 0% 1.68M ± 0% +11.89% .debug_line 338k ± 0% 435k ± 0% +28.78% Total 9.21M ± 0% 9.58M ± 0% +4.01% Updates #19348. Change-Id: Ic4f180c3b516018138236b0c35e0218270d957d3 Reviewed-on: https://go-review.googlesource.com/37231 Run-TryBot: David Lazar <lazard@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2017-02-17 12:28:05 -05:00
// Line returns n's position as a string. If n has been inlined,
// it uses the outermost position where n has been inlined.
func (n *Node) Line() string {
[dev.inline] cmd/internal/src: replace src.Pos with syntax.Pos This replaces the src.Pos LineHist-based position tracking with the syntax.Pos implementation and updates all uses. The LineHist table is not used anymore - the respective code is still there but should be removed eventually. CL forthcoming. Passes toolstash -cmp when comparing to the master repo (with the exception of a couple of swapped assembly instructions, likely due to different instruction scheduling because the line-based sorting has changed; though this is won't affect correctness). The sizes of various important compiler data structures have increased significantly (see the various sizes_test.go files); this is probably the reason for an increase of compilation times (to be addressed). Here are the results of compilebench -count 5, run on a "quiet" machine (no apps running besides a terminal): name old time/op new time/op delta Template 256ms ± 1% 280ms ±15% +9.54% (p=0.008 n=5+5) Unicode 132ms ± 1% 132ms ± 1% ~ (p=0.690 n=5+5) GoTypes 891ms ± 1% 917ms ± 2% +2.88% (p=0.008 n=5+5) Compiler 3.84s ± 2% 3.99s ± 2% +3.95% (p=0.016 n=5+5) MakeBash 47.1s ± 1% 47.2s ± 2% ~ (p=0.841 n=5+5) name old user-ns/op new user-ns/op delta Template 309M ± 1% 326M ± 2% +5.18% (p=0.008 n=5+5) Unicode 165M ± 1% 168M ± 4% ~ (p=0.421 n=5+5) GoTypes 1.14G ± 2% 1.18G ± 1% +3.47% (p=0.008 n=5+5) Compiler 5.00G ± 1% 5.16G ± 1% +3.12% (p=0.008 n=5+5) Change-Id: I241c4246cdff627d7ecb95cac23060b38f9775ec Reviewed-on: https://go-review.googlesource.com/34273 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2016-12-09 17:15:05 -08:00
return linestr(n.Pos)
}
var atExitFuncs []func()
func atExit(f func()) {
atExitFuncs = append(atExitFuncs, f)
}
func Exit(code int) {
for i := len(atExitFuncs) - 1; i >= 0; i-- {
f := atExitFuncs[i]
atExitFuncs = atExitFuncs[:i]
f()
}
os.Exit(code)
}
var (
blockprofile string
cpuprofile string
memprofile string
memprofilerate int64
traceprofile string
traceHandler func(string)
mutexprofile string
)
func startProfile() {
if cpuprofile != "" {
f, err := os.Create(cpuprofile)
if err != nil {
Fatalf("%v", err)
}
if err := pprof.StartCPUProfile(f); err != nil {
Fatalf("%v", err)
}
atExit(pprof.StopCPUProfile)
}
if memprofile != "" {
if memprofilerate != 0 {
runtime.MemProfileRate = int(memprofilerate)
}
f, err := os.Create(memprofile)
if err != nil {
Fatalf("%v", err)
}
atExit(func() {
// Profile all outstanding allocations.
runtime.GC()
// compilebench parses the memory profile to extract memstats,
// which are only written in the legacy pprof format.
// See golang.org/issue/18641 and runtime/pprof/pprof.go:writeHeap.
const writeLegacyFormat = 1
if err := pprof.Lookup("heap").WriteTo(f, writeLegacyFormat); err != nil {
Fatalf("%v", err)
}
})
cmd/compile: disable memory profiling when not in use The default value of runtime.MemProfileRate is non-zero, which means that a small portion of allocations go through the (slow) profiled allocation path. This is never useful in the compiler unless the -memprofile flag has been passed. I noticed this when samples from mprof.go showed up in a compiler cpu pprof listing. name old time/op new time/op delta Template 207ms ± 4% 205ms ± 4% -0.86% (p=0.001 n=97+90) Unicode 91.8ms ± 4% 91.4ms ± 4% -0.44% (p=0.030 n=93+93) GoTypes 628ms ± 4% 624ms ± 3% -0.73% (p=0.001 n=95+92) Compiler 2.70s ± 3% 2.69s ± 3% -0.39% (p=0.000 n=97+95) Flate 131ms ± 5% 130ms ± 4% -0.82% (p=0.000 n=93+90) GoParser 154ms ± 5% 153ms ± 4% -0.57% (p=0.019 n=98+96) Reflect 394ms ± 5% 392ms ± 5% -0.62% (p=0.026 n=94+97) Tar 112ms ± 6% 112ms ± 5% ~ (p=0.455 n=97+98) XML 214ms ± 3% 213ms ± 4% -0.68% (p=0.000 n=91+93) name old user-ns/op new user-ns/op delta Template 246user-ms ± 3% 244user-ms ± 4% -0.48% (p=0.016 n=92+91) Unicode 114user-ms ± 5% 113user-ms ± 4% -0.78% (p=0.002 n=98+94) GoTypes 817user-ms ± 3% 813user-ms ± 2% -0.50% (p=0.006 n=96+94) Compiler 3.58user-s ± 2% 3.57user-s ± 2% -0.38% (p=0.003 n=97+95) Flate 158user-ms ± 5% 157user-ms ± 4% -0.80% (p=0.000 n=94+90) GoParser 191user-ms ± 4% 191user-ms ± 4% ~ (p=0.122 n=98+98) Reflect 500user-ms ± 4% 498user-ms ± 4% ~ (p=0.057 n=95+99) Tar 134user-ms ± 3% 134user-ms ± 4% ~ (p=0.529 n=98+98) XML 265user-ms ± 3% 265user-ms ± 3% -0.30% (p=0.033 n=92+96) Change-Id: Ied5384e337800d567895ff8d47f15d631edf4f0b Reviewed-on: https://go-review.googlesource.com/35916 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-01-27 14:04:23 -08:00
} else {
// Not doing memory profiling; disable it entirely.
runtime.MemProfileRate = 0
}
if blockprofile != "" {
f, err := os.Create(blockprofile)
if err != nil {
Fatalf("%v", err)
}
runtime.SetBlockProfileRate(1)
atExit(func() {
pprof.Lookup("block").WriteTo(f, 0)
f.Close()
})
}
if mutexprofile != "" {
f, err := os.Create(mutexprofile)
if err != nil {
Fatalf("%v", err)
}
startMutexProfiling()
atExit(func() {
pprof.Lookup("mutex").WriteTo(f, 0)
f.Close()
})
}
if traceprofile != "" && traceHandler != nil {
traceHandler(traceprofile)
}
}