An error occurred fetching the project authors.
  1. 08 Jan, 2019 1 commit
    • Keith Randall's avatar
      runtime: store incremented PC in result of runtime.Callers · 232c9793
      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: default avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      232c9793
  2. 28 Dec, 2018 1 commit
    • Keith Randall's avatar
      cmd/compile,runtime: redo mid-stack inlining tracebacks · 69c2c564
      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: default avatarDavid Chase <drchase@google.com>
      69c2c564
  3. 29 Aug, 2018 1 commit
  4. 24 Apr, 2018 1 commit
    • Hana (Hyang-Ah) Kim's avatar
      runtime/pprof: introduce "allocs" profile · cd037bce
      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: default avatarRuss Cox <rsc@golang.org>
      cd037bce
  5. 15 May, 2017 1 commit
    • Austin Clements's avatar
      runtime/pprof: clean up call/return PCs in memory profiles · 1dc0f969
      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: default avatarMichael Matloob <matloob@golang.org>
      1dc0f969
  6. 24 Feb, 2017 3 commits
    • Russ Cox's avatar
      runtime/pprof/internal/profile: move internal/pprof/profile here · 0b8c983e
      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: default avatarMichael Matloob <matloob@golang.org>
      0b8c983e
    • Russ Cox's avatar
      runtime/pprof: add streaming protobuf encoder · cbab65fd
      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: default avatarMichael Matloob <matloob@golang.org>
      cbab65fd
    • Russ Cox's avatar
      runtime/pprof: use new profile buffers for CPU profiling · 1a680a90
      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: default avatarMichael Matloob <matloob@golang.org>
      1a680a90
  7. 14 Feb, 2017 1 commit
  8. 10 Feb, 2017 1 commit
  9. 22 Nov, 2016 2 commits