2009-05-08 16:55:45 -06:00
|
|
|
// Copyright 2009 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.
|
|
|
|
|
|
|
|
/*
|
2013-03-14 23:11:03 -06:00
|
|
|
Package runtime contains operations that interact with Go's runtime system,
|
|
|
|
such as functions to control goroutines. It also includes the low-level type information
|
|
|
|
used by the reflect package; see reflect's documentation for the programmable
|
|
|
|
interface to the run-time type system.
|
|
|
|
|
|
|
|
Environment Variables
|
|
|
|
|
|
|
|
The following environment variables ($name or %name%, depending on the host
|
|
|
|
operating system) control the run-time behavior of Go programs. The meanings
|
|
|
|
and use may change from release to release.
|
|
|
|
|
|
|
|
The GOGC variable sets the initial garbage collection target percentage.
|
|
|
|
A collection is triggered when the ratio of freshly allocated data to live data
|
|
|
|
remaining after the previous collection reaches this percentage. The default
|
|
|
|
is GOGC=100. Setting GOGC=off disables the garbage collector entirely.
|
|
|
|
The runtime/debug package's SetGCPercent function allows changing this
|
2015-07-10 17:17:11 -06:00
|
|
|
percentage at run time. See https://golang.org/pkg/runtime/debug/#SetGCPercent.
|
2013-03-14 23:11:03 -06:00
|
|
|
|
2015-06-05 09:51:49 -06:00
|
|
|
The GODEBUG variable controls debugging variables within the runtime.
|
|
|
|
It is a comma-separated list of name=val pairs setting these named variables:
|
2013-08-13 14:30:55 -06:00
|
|
|
|
2013-12-06 15:40:45 -07:00
|
|
|
allocfreetrace: setting allocfreetrace=1 causes every allocation to be
|
|
|
|
profiled and a stack trace printed on each object's allocation and free.
|
|
|
|
|
2015-11-13 18:45:22 -07:00
|
|
|
cgocheck: setting cgocheck=0 disables all checks for packages
|
|
|
|
using cgo to incorrectly pass Go pointers to non-Go code.
|
|
|
|
Setting cgocheck=1 (the default) enables relatively cheap
|
|
|
|
checks that may miss some errors. Setting cgocheck=2 enables
|
|
|
|
expensive checks that should not miss any errors, but will
|
|
|
|
cause your program to run slower.
|
|
|
|
|
2013-12-06 15:40:45 -07:00
|
|
|
efence: setting efence=1 causes the allocator to run in a mode
|
|
|
|
where each object is allocated on a unique page and addresses are
|
|
|
|
never recycled.
|
|
|
|
|
2015-06-05 09:51:49 -06:00
|
|
|
gccheckmark: setting gccheckmark=1 enables verification of the
|
|
|
|
garbage collector's concurrent mark phase by performing a
|
|
|
|
second mark pass while the world is stopped. If the second
|
|
|
|
pass finds a reachable object that was not found by concurrent
|
|
|
|
mark, the garbage collector will panic.
|
|
|
|
|
|
|
|
gcpacertrace: setting gcpacertrace=1 causes the garbage collector to
|
|
|
|
print information about the internal state of the concurrent pacer.
|
|
|
|
|
|
|
|
gcshrinkstackoff: setting gcshrinkstackoff=1 disables moving goroutines
|
|
|
|
onto smaller stacks. In this mode, a goroutine's stack can only grow.
|
|
|
|
|
runtime: disable stack rescanning by default
With the hybrid barrier in place, we can now disable stack rescanning
by default. This commit adds a "gcrescanstacks" GODEBUG variable that
is off by default but can be set to re-enable STW stack rescanning.
The plan is to leave this off but available in Go 1.8 for debugging
and as a fallback.
With this change, worst-case mark termination time at GOMAXPROCS=12
*not* including time spent stopping the world (which is still
unbounded) is reliably under 100 µs, with a 95%ile around 50 µs in
every benchmark I tried (the go1 benchmarks, the x/benchmarks garbage
benchmark, and the gcbench activegs and rpc benchmarks). Including
time spent stopping the world usually adds about 20 µs to total STW
time at GOMAXPROCS=12, but I've seen it add around 150 µs in these
benchmarks when a goroutine takes time to reach a safe point (see
issue #10958) or when stopping the world races with goroutine
switches. At GOMAXPROCS=1, where this isn't an issue, worst case STW
is typically 30 µs.
The go-gcbench activegs benchmark is designed to stress large numbers
of dirty stacks. This commit reduces 95%ile STW time for 500k dirty
stacks by nearly three orders of magnitude, from 150ms to 195µs.
This has little effect on the throughput of the go1 benchmarks or the
x/benchmarks benchmarks.
name old time/op new time/op delta
XGarbage-12 2.31ms ± 0% 2.32ms ± 1% +0.28% (p=0.001 n=17+16)
XJSON-12 12.4ms ± 0% 12.4ms ± 0% +0.41% (p=0.000 n=18+18)
XHTTP-12 11.8µs ± 0% 11.8µs ± 1% ~ (p=0.492 n=20+18)
It reduces the tail latency of the x/benchmarks HTTP benchmark:
name old p50-time new p50-time delta
XHTTP-12 489µs ± 0% 491µs ± 1% +0.54% (p=0.000 n=20+18)
name old p95-time new p95-time delta
XHTTP-12 957µs ± 1% 960µs ± 1% +0.28% (p=0.002 n=20+17)
name old p99-time new p99-time delta
XHTTP-12 1.76ms ± 1% 1.64ms ± 1% -7.20% (p=0.000 n=20+18)
Comparing to the beginning of the hybrid barrier implementation
("runtime: parallelize STW mcache flushing") shows that the hybrid
barrier trades a small performance impact for much better STW latency,
as expected. The magnitude of the performance impact is generally
small:
name old time/op new time/op delta
BinaryTree17-12 2.37s ± 1% 2.42s ± 1% +2.04% (p=0.000 n=19+18)
Fannkuch11-12 2.84s ± 0% 2.72s ± 0% -4.00% (p=0.000 n=19+19)
FmtFprintfEmpty-12 44.2ns ± 1% 45.2ns ± 1% +2.20% (p=0.000 n=17+19)
FmtFprintfString-12 130ns ± 1% 134ns ± 0% +2.94% (p=0.000 n=18+16)
FmtFprintfInt-12 114ns ± 1% 117ns ± 0% +3.01% (p=0.000 n=19+15)
FmtFprintfIntInt-12 176ns ± 1% 182ns ± 0% +3.17% (p=0.000 n=20+15)
FmtFprintfPrefixedInt-12 186ns ± 1% 187ns ± 1% +1.04% (p=0.000 n=20+19)
FmtFprintfFloat-12 251ns ± 1% 250ns ± 1% -0.74% (p=0.000 n=17+18)
FmtManyArgs-12 746ns ± 1% 761ns ± 0% +2.08% (p=0.000 n=19+20)
GobDecode-12 6.57ms ± 1% 6.65ms ± 1% +1.11% (p=0.000 n=19+20)
GobEncode-12 5.59ms ± 1% 5.65ms ± 0% +1.08% (p=0.000 n=17+17)
Gzip-12 223ms ± 1% 223ms ± 1% -0.31% (p=0.006 n=20+20)
Gunzip-12 38.0ms ± 0% 37.9ms ± 1% -0.25% (p=0.009 n=19+20)
HTTPClientServer-12 77.5µs ± 1% 78.9µs ± 2% +1.89% (p=0.000 n=20+20)
JSONEncode-12 14.7ms ± 1% 14.9ms ± 0% +0.75% (p=0.000 n=20+20)
JSONDecode-12 53.0ms ± 1% 55.9ms ± 1% +5.54% (p=0.000 n=19+19)
Mandelbrot200-12 3.81ms ± 0% 3.81ms ± 1% +0.20% (p=0.023 n=17+19)
GoParse-12 3.17ms ± 1% 3.18ms ± 1% ~ (p=0.057 n=20+19)
RegexpMatchEasy0_32-12 71.7ns ± 1% 70.4ns ± 1% -1.77% (p=0.000 n=19+20)
RegexpMatchEasy0_1K-12 946ns ± 0% 946ns ± 0% ~ (p=0.405 n=18+18)
RegexpMatchEasy1_32-12 67.2ns ± 2% 67.3ns ± 2% ~ (p=0.732 n=20+20)
RegexpMatchEasy1_1K-12 374ns ± 1% 378ns ± 1% +1.14% (p=0.000 n=18+19)
RegexpMatchMedium_32-12 107ns ± 1% 107ns ± 1% ~ (p=0.259 n=18+20)
RegexpMatchMedium_1K-12 34.2µs ± 1% 34.5µs ± 1% +1.03% (p=0.000 n=18+18)
RegexpMatchHard_32-12 1.77µs ± 1% 1.79µs ± 1% +0.73% (p=0.000 n=19+18)
RegexpMatchHard_1K-12 53.6µs ± 1% 54.2µs ± 1% +1.10% (p=0.000 n=19+19)
Template-12 61.5ms ± 1% 63.9ms ± 0% +3.96% (p=0.000 n=18+18)
TimeParse-12 303ns ± 1% 300ns ± 1% -1.08% (p=0.000 n=19+20)
TimeFormat-12 318ns ± 1% 320ns ± 0% +0.79% (p=0.000 n=19+19)
Revcomp-12 (*) 509ms ± 3% 504ms ± 0% ~ (p=0.967 n=7+12)
[Geo mean] 54.3µs 54.8µs +0.88%
(*) Revcomp is highly non-linear, so I only took samples with 2
iterations.
name old time/op new time/op delta
XGarbage-12 2.25ms ± 0% 2.32ms ± 1% +2.74% (p=0.000 n=16+16)
XJSON-12 11.6ms ± 0% 12.4ms ± 0% +6.81% (p=0.000 n=18+18)
XHTTP-12 11.6µs ± 1% 11.8µs ± 1% +1.62% (p=0.000 n=17+18)
Updates #17503.
Updates #17099, since you can't have a rescan list bug if there's no
rescan list. I'm not marking it as fixed, since gcrescanstacks can
still be set to re-enable the rescan lists.
Change-Id: I6e926b4c2dbd4cd56721869d4f817bdbb330b851
Reviewed-on: https://go-review.googlesource.com/31766
Reviewed-by: Rick Hudson <rlh@golang.org>
2016-10-23 09:07:49 -06:00
|
|
|
gcrescanstacks: setting gcrescanstacks=1 enables stack
|
|
|
|
re-scanning during the STW mark termination phase. This is
|
|
|
|
helpful for debugging if objects are being prematurely
|
|
|
|
garbage collected.
|
|
|
|
|
2015-06-05 09:51:49 -06:00
|
|
|
gcstoptheworld: setting gcstoptheworld=1 disables concurrent garbage collection,
|
|
|
|
making every garbage collection a stop-the-world event. Setting gcstoptheworld=2
|
|
|
|
also disables concurrent sweeping after the garbage collection finishes.
|
|
|
|
|
2013-08-13 14:30:55 -06:00
|
|
|
gctrace: setting gctrace=1 causes the garbage collector to emit a single line to standard
|
|
|
|
error at each collection, summarizing the amount of memory collected and the
|
|
|
|
length of the pause. Setting gctrace=2 emits the same summary but also
|
2015-07-21 09:45:55 -06:00
|
|
|
repeats each collection. The format of this line is subject to change.
|
|
|
|
Currently, it is:
|
2016-01-08 12:57:26 -07:00
|
|
|
gc # @#s #%: #+#+# ms clock, #+#/#/#+# ms cpu, #->#-># MB, # MB goal, # P
|
2015-07-21 09:45:55 -06:00
|
|
|
where the fields are as follows:
|
|
|
|
gc # the GC number, incremented at each GC
|
|
|
|
@#s time in seconds since program start
|
|
|
|
#% percentage of time spent in GC since program start
|
|
|
|
#+...+# wall-clock/CPU times for the phases of the GC
|
|
|
|
#->#-># MB heap size at GC start, at GC end, and live heap
|
|
|
|
# MB goal goal heap size
|
|
|
|
# P number of processors used
|
2016-01-08 12:57:26 -07:00
|
|
|
The phases are stop-the-world (STW) sweep termination, concurrent
|
|
|
|
mark and scan, and STW mark termination. The CPU times
|
|
|
|
for mark/scan are broken down in to assist time (GC performed in
|
2015-07-21 09:45:55 -06:00
|
|
|
line with allocation), background GC time, and idle GC time.
|
|
|
|
If the line ends with "(forced)", this GC was forced by a
|
|
|
|
runtime.GC() call and all phases are STW.
|
2013-08-13 14:30:55 -06:00
|
|
|
|
2016-05-22 03:20:11 -06:00
|
|
|
Setting gctrace to any value > 0 also causes the garbage collector
|
|
|
|
to emit a summary when memory is released back to the system.
|
|
|
|
This process of returning memory to the system is called scavenging.
|
|
|
|
The format of this summary is subject to change.
|
|
|
|
Currently it is:
|
|
|
|
scvg#: # MB released printed only if non-zero
|
|
|
|
scvg#: inuse: # idle: # sys: # released: # consumed: # (MB)
|
|
|
|
where the fields are as follows:
|
|
|
|
scvg# the scavenge cycle number, incremented at each scavenge
|
|
|
|
inuse: # MB used or partially used spans
|
|
|
|
idle: # MB spans pending scavenging
|
|
|
|
sys: # MB mapped from the system
|
|
|
|
released: # MB released to the system
|
|
|
|
consumed: # MB allocated from the system
|
|
|
|
|
2015-06-05 09:51:49 -06:00
|
|
|
memprofilerate: setting memprofilerate=X will update the value of runtime.MemProfileRate.
|
|
|
|
When set to 0 memory profiling is disabled. Refer to the description of
|
|
|
|
MemProfileRate for the default value.
|
2014-03-25 15:11:34 -06:00
|
|
|
|
2014-10-28 19:53:31 -06:00
|
|
|
invalidptr: defaults to invalidptr=1, causing the garbage collector and stack
|
|
|
|
copier to crash the program if an invalid pointer value (for example, 1)
|
|
|
|
is found in a pointer-typed location. Setting invalidptr=0 disables this check.
|
|
|
|
This should only be used as a temporary workaround to diagnose buggy code.
|
|
|
|
The real fix is to not store integers in pointer-typed locations.
|
|
|
|
|
2015-06-05 09:51:49 -06:00
|
|
|
sbrk: setting sbrk=1 replaces the memory allocator and garbage collector
|
|
|
|
with a trivial allocator that obtains memory from the operating system and
|
|
|
|
never reclaims any memory.
|
|
|
|
|
|
|
|
scavenge: scavenge=1 enables debugging mode of heap scavenger.
|
2015-01-28 11:28:59 -07:00
|
|
|
|
2013-08-13 14:30:55 -06:00
|
|
|
scheddetail: setting schedtrace=X and scheddetail=1 causes the scheduler to emit
|
|
|
|
detailed multiline info every X milliseconds, describing state of the scheduler,
|
|
|
|
processors, threads and goroutines.
|
2013-03-14 23:11:03 -06:00
|
|
|
|
2013-12-06 15:40:45 -07:00
|
|
|
schedtrace: setting schedtrace=X causes the scheduler to emit a single line to standard
|
|
|
|
error every X milliseconds, summarizing the scheduler state.
|
2013-12-03 15:42:38 -07:00
|
|
|
|
2016-01-06 20:04:06 -07:00
|
|
|
The net and net/http packages also refer to debugging variables in GODEBUG.
|
|
|
|
See the documentation for those packages for details.
|
|
|
|
|
2013-03-14 23:11:03 -06:00
|
|
|
The GOMAXPROCS variable limits the number of operating system threads that
|
|
|
|
can execute user-level Go code simultaneously. There is no limit to the number of threads
|
|
|
|
that can be blocked in system calls on behalf of Go code; those do not count against
|
|
|
|
the GOMAXPROCS limit. This package's GOMAXPROCS function queries and changes
|
|
|
|
the limit.
|
|
|
|
|
|
|
|
The GOTRACEBACK variable controls the amount of output generated when a Go
|
|
|
|
program fails due to an unrecovered panic or an unexpected runtime condition.
|
2015-10-30 09:03:02 -06:00
|
|
|
By default, a failure prints a stack trace for the current goroutine,
|
|
|
|
eliding functions internal to the run-time system, and then exits with exit code 2.
|
|
|
|
The failure prints stack traces for all goroutines if there is no current goroutine
|
|
|
|
or the failure is internal to the run-time.
|
|
|
|
GOTRACEBACK=none omits the goroutine stack traces entirely.
|
|
|
|
GOTRACEBACK=single (the default) behaves as described above.
|
|
|
|
GOTRACEBACK=all adds stack traces for all user-created goroutines.
|
|
|
|
GOTRACEBACK=system is like ``all'' but adds stack frames for run-time functions
|
|
|
|
and shows goroutines created internally by the run-time.
|
|
|
|
GOTRACEBACK=crash is like ``system'' but crashes in an operating system-specific
|
|
|
|
manner instead of exiting. For example, on Unix systems, the crash raises
|
|
|
|
SIGABRT to trigger a core dump.
|
|
|
|
For historical reasons, the GOTRACEBACK settings 0, 1, and 2 are synonyms for
|
|
|
|
none, all, and system, respectively.
|
2015-12-18 09:19:38 -07:00
|
|
|
The runtime/debug package's SetTraceback function allows increasing the
|
|
|
|
amount of output at run time, but it cannot reduce the amount below that
|
|
|
|
specified by the environment variable.
|
|
|
|
See https://golang.org/pkg/runtime/debug/#SetTraceback.
|
2013-03-14 23:11:03 -06:00
|
|
|
|
|
|
|
The GOARCH, GOOS, GOPATH, and GOROOT environment variables complete
|
|
|
|
the set of Go environment variables. They influence the building of Go programs
|
2015-07-10 17:17:11 -06:00
|
|
|
(see https://golang.org/cmd/go and https://golang.org/pkg/go/build).
|
2013-03-14 23:11:03 -06:00
|
|
|
GOARCH, GOOS, and GOROOT are recorded at compile time and made available by
|
|
|
|
constants or functions in this package, but they do not influence the execution
|
|
|
|
of the run-time system.
|
2009-11-05 16:37:55 -07:00
|
|
|
*/
|
2009-05-08 16:55:45 -06:00
|
|
|
package runtime
|
|
|
|
|
2015-11-11 10:39:30 -07:00
|
|
|
import "runtime/internal/sys"
|
|
|
|
|
2009-05-08 16:55:45 -06:00
|
|
|
// Caller reports file and line number information about function invocations on
|
2016-03-01 16:21:55 -07:00
|
|
|
// the calling goroutine's stack. The argument skip is the number of stack frames
|
2012-05-24 15:15:43 -06:00
|
|
|
// to ascend, with 0 identifying the caller of Caller. (For historical reasons the
|
2012-04-09 17:47:57 -06:00
|
|
|
// meaning of skip differs between Caller and Callers.) The return values report the
|
2009-05-08 16:55:45 -06:00
|
|
|
// program counter, file name, and line number within the file of the corresponding
|
2016-03-01 16:21:55 -07:00
|
|
|
// call. The boolean ok is false if it was not possible to recover the information.
|
2014-08-28 08:46:59 -06:00
|
|
|
func Caller(skip int) (pc uintptr, file string, line int, ok bool) {
|
2017-04-10 12:33:07 -06:00
|
|
|
// Make room for three PCs: the one we were asked for,
|
|
|
|
// what it called, so that CallersFrames can see if it "called"
|
|
|
|
// sigpanic, and possibly a PC for skipPleaseUseCallersFrames.
|
|
|
|
var rpc [3]uintptr
|
2015-02-24 22:41:21 -07:00
|
|
|
if callers(1+skip-1, rpc[:]) < 2 {
|
2014-08-28 08:46:59 -06:00
|
|
|
return
|
|
|
|
}
|
2017-04-10 12:33:07 -06:00
|
|
|
var stackExpander stackExpander
|
|
|
|
callers := stackExpander.init(rpc[:])
|
|
|
|
// We asked for one extra, so skip that one. If this is sigpanic,
|
|
|
|
// stepping over this frame will set up state in Frames so the
|
|
|
|
// next frame is correct.
|
|
|
|
callers, _, ok = stackExpander.next(callers)
|
|
|
|
if !ok {
|
2014-08-28 08:46:59 -06:00
|
|
|
return
|
|
|
|
}
|
2017-04-10 12:33:07 -06:00
|
|
|
_, frame, _ := stackExpander.next(callers)
|
|
|
|
pc = frame.PC
|
|
|
|
file = frame.File
|
|
|
|
line = frame.Line
|
2014-08-28 08:46:59 -06:00
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2014-10-29 13:14:04 -06:00
|
|
|
// Callers fills the slice pc with the return program counters of function invocations
|
2016-03-01 16:21:55 -07:00
|
|
|
// on the calling goroutine's stack. The argument skip is the number of stack frames
|
2012-05-24 15:15:43 -06:00
|
|
|
// to skip before recording in pc, with 0 identifying the frame for Callers itself and
|
|
|
|
// 1 identifying the caller of Callers.
|
2010-03-23 21:48:23 -06:00
|
|
|
// It returns the number of entries written to pc.
|
2014-10-29 13:14:04 -06:00
|
|
|
//
|
2017-03-06 12:13:24 -07:00
|
|
|
// To translate these PCs into symbolic information such as function
|
|
|
|
// names and line numbers, use CallersFrames. CallersFrames accounts
|
|
|
|
// for inlined functions and adjusts the return program counters into
|
|
|
|
// call program counters. Iterating over the returned slice of PCs
|
|
|
|
// directly is discouraged, as is using FuncForPC on any of the
|
|
|
|
// returned PCs, since these cannot account for inlining or return
|
|
|
|
// program counter adjustment.
|
2014-08-28 08:46:59 -06:00
|
|
|
func Callers(skip int, pc []uintptr) int {
|
|
|
|
// runtime.callers uses pc.array==nil as a signal
|
2016-03-01 16:21:55 -07:00
|
|
|
// to print a stack trace. Pick off 0-length pc here
|
2014-08-28 08:46:59 -06:00
|
|
|
// so that we don't let a nil pc slice get to it.
|
|
|
|
if len(pc) == 0 {
|
|
|
|
return 0
|
|
|
|
}
|
2015-02-24 22:41:21 -07:00
|
|
|
return callers(skip, pc)
|
2014-08-28 08:46:59 -06:00
|
|
|
}
|
|
|
|
|
2010-03-17 00:10:33 -06:00
|
|
|
// GOROOT returns the root of the Go tree.
|
|
|
|
// It uses the GOROOT environment variable, if set,
|
|
|
|
// or else the root used during the Go build.
|
|
|
|
func GOROOT() string {
|
2014-08-28 08:46:59 -06:00
|
|
|
s := gogetenv("GOROOT")
|
2010-03-17 00:10:33 -06:00
|
|
|
if s != "" {
|
|
|
|
return s
|
|
|
|
}
|
2015-11-11 10:39:30 -07:00
|
|
|
return sys.DefaultGoroot
|
2010-03-17 00:10:33 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// Version returns the Go tree's version string.
|
2014-05-20 12:41:24 -06:00
|
|
|
// It is either the commit hash and date at the time of the build or,
|
|
|
|
// when possible, a release tag like "go1.3".
|
2010-09-02 12:19:12 -06:00
|
|
|
func Version() string {
|
2015-11-11 10:39:30 -07:00
|
|
|
return sys.TheVersion
|
2010-09-02 12:19:12 -06:00
|
|
|
}
|
|
|
|
|
2012-02-16 14:49:41 -07:00
|
|
|
// GOOS is the running program's operating system target:
|
2010-09-02 12:19:12 -06:00
|
|
|
// one of darwin, freebsd, linux, and so on.
|
2016-04-07 00:42:35 -06:00
|
|
|
const GOOS string = sys.GOOS
|
2010-09-02 12:19:12 -06:00
|
|
|
|
2012-02-16 14:49:41 -07:00
|
|
|
// GOARCH is the running program's architecture target:
|
2017-04-19 11:48:33 -06:00
|
|
|
// one of 386, amd64, arm, s390x, and so on.
|
2016-04-07 00:42:35 -06:00
|
|
|
const GOARCH string = sys.GOARCH
|