An error occurred fetching the project authors.
- 08 Jan, 2019 1 commit
-
-
Keith Randall authored
In 1.11 we stored "return addresses" in the result of runtime.Callers. I changed that behavior in CL 152537 to store an address in the call instruction itself. This CL reverts that part of 152537. The change in 152537 was made because we now store pcs of inline marks in the result of runtime.Callers as well. This CL will now store the address of the inline mark + 1 in the results of runtime.Callers, so that the subsequent -1 done in CallersFrames will pick out the correct inline mark instruction. This CL means that the results of runtime.Callers can be passed to runtime.FuncForPC as they were before. There are a bunch of packages in the wild that take the results of runtime.Callers, subtract 1, and then call FuncForPC. This CL keeps that pattern working as it did in 1.11. The changes to runtime/pprof in this CL are exactly a revert of the changes to that package in 152537 (except the locForPC comment). Update #29582 Change-Id: I04d232000fb482f0f0ff6277f8d7b9c72e97eb48 Reviewed-on: https://go-review.googlesource.com/c/156657Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 28 Dec, 2018 1 commit
-
-
Keith Randall authored
Work involved in getting a stack trace is divided between runtime.Callers and runtime.CallersFrames. Before this CL, runtime.Callers returns a pc per runtime frame. runtime.CallersFrames is responsible for expanding a runtime frame into potentially multiple user frames. After this CL, runtime.Callers returns a pc per user frame. runtime.CallersFrames just maps those to user frame info. Entries in the result of runtime.Callers are now pcs of the calls (or of the inline marks), not of the instruction just after the call. Fixes #29007 Fixes #28640 Update #26320 Change-Id: I1c9567596ff73dc73271311005097a9188c3406f Reviewed-on: https://go-review.googlesource.com/c/152537 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Chase <drchase@google.com>
-
- 29 Aug, 2018 1 commit
-
-
Alexey Alexandrov authored
Fixes #26638. Change-Id: I3c18d1298d99af8ea8c00916303efd2b5a5effc7 Reviewed-on: https://go-review.googlesource.com/126336Reviewed-by:
Hyang-Ah Hana Kim <hyangah@gmail.com> Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 24 Apr, 2018 1 commit
-
-
Hana (Hyang-Ah) Kim authored
The Go's heap profile contains four kinds of samples (inuse_space, inuse_objects, alloc_space, and alloc_objects). The pprof tool by default chooses the inuse_space (the bytes of live, in-use objects). When analyzing the current memory usage the choice of inuse_space as the default may be useful, but in some cases, users are more interested in analyzing the total allocation statistics throughout the program execution. For example, when we analyze the memory profile from benchmark or program test run, we are more likely interested in the whole allocation history than the live heap snapshot at the end of the test or benchmark. The pprof tool provides flags to control which sample type to be used for analysis. However, it is one of the less-known features of pprof and we believe it's better to choose the right type of samples as the default when producing the profile. This CL introduces a new type of profile, "allocs", which is the same as the "heap" profile but marks the alloc_space as the default type unlike heap profiles that use inuse_space as the default type. 'go test -memprofile=...' command is changed to use the new "allocs" profile type instead of the traditional "heap" profile. Fixes #24443 Change-Id: I012dd4b6dcacd45644d7345509936b8380b6fbd9 Reviewed-on: https://go-review.googlesource.com/102696 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 15 May, 2017 1 commit
-
-
Austin Clements authored
Proto profile conversion is inconsistent about call vs return PCs in profile locations. The proto defines locations to be call PCs. This is what we do when proto-izing CPU profiles, but we fail to convert the return PCs in memory and count profile stacks to call PCs when converting them to proto locations. Fix this in the heap and count profile conversion functions. TestConvertMemProfile also hard-codes this failure to convert from return PCs to call PCs, so fix up the addresses in the synthesized profile to be return PCs while checking that we get call PCs out of the conversion. Change-Id: If1fc028b86fceac6d71a2d9fa6c41ff442c89296 Reviewed-on: https://go-review.googlesource.com/42951 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Matloob <matloob@golang.org>
-
- 24 Feb, 2017 3 commits
-
-
Russ Cox authored
Nothing needs internal/pprof anymore except the runtime/pprof tests. Move the package here to prevent new dependencies. Change-Id: Ia119af91cc2b980e0fa03a15f46f69d7f71d2926 Reviewed-on: https://go-review.googlesource.com/37165 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Matloob <matloob@golang.org>
-
Russ Cox authored
The existing code builds a full profile in memory. Then it translates that profile into a data structure (in memory). Then it marshals that data structure into a protocol buffer (in memory). Then it gzips that marshaled form into the underlying writer. So there are three copies of the full profile data in memory at the same time before we're done. This is obviously dumb. This CL implements a fully streaming conversion from the original in-memory profile to the underlying writer. There is now only one copy of the profile in memory. For the non-CPU profiles, this is optimal, since we have to have a full copy in memory to start with. For the CPU profiles, we could still try to bound the profile size stored in memory and stream fragments out during the actual profiling, as Go 1.7 did (with a simpler format), but so far that hasn't been necessary. Change-Id: Ic36141021857791bf0cd1fce84178fb5e744b989 Reviewed-on: https://go-review.googlesource.com/37164 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Michael Matloob <matloob@golang.org>
-
Russ Cox authored
This doesn't change the functionality of the current code, but it sets us up for exporting the profiling labels into the profile. The old code had a hash table of profile samples maintained during the signal handler, with evictions going into a log. The new code just logs every sample directly, leaving the hash-based deduplication to an ordinary goroutine. The new code also avoids storing the entire profile in two forms in memory, an unfortunate regression introduced when binary profile support was added. After this CL the entire profile is only stored once in memory. We'd still like to get back down to storing it zero times (streaming it to the underlying io.Writer). Change-Id: I0893a1788267c564aa1af17970d47377b2a43457 Reviewed-on: https://go-review.googlesource.com/36712 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Matloob <matloob@golang.org>
-
- 14 Feb, 2017 1 commit
-
-
Josh Bleecher Snyder authored
Makes vet happy. Change-Id: I7250f283c96e82b9796c5672a0a143ba7568fa63 Reviewed-on: https://go-review.googlesource.com/36937 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 10 Feb, 2017 1 commit
-
-
Russ Cox authored
These are very tightly coupled, and internal/protopprof is small. There's no point to having a separate package. Change-Id: I2c8aa49c9e18a7128657bf2b05323860151b5606 Reviewed-on: https://go-review.googlesource.com/36711 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 22 Nov, 2016 2 commits
-
-
Michael Munday authored
Applies the fix from CL 32920 to the new test TestSampledHeapAllocProfile introduced in CL 33422. The test should be skipped rather than fail if there is only one executable region of memory. Updates #17852. Change-Id: Id8c47b1f17ead14f02a58a024c9a04ebb8ec0429 Reviewed-on: https://go-review.googlesource.com/33453 Run-TryBot: Michael Munday <munday@ca.ibm.com> Reviewed-by:
Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Matloob authored
When debug is 0, emit the compressed proto format. The debug>0 format stays the same. Updates #16093 Change-Id: I45aa1874a22d34cf44dd4aa78bbff9302381cb34 Reviewed-on: https://go-review.googlesource.com/33422 Run-TryBot: Michael Matloob <matloob@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-