1. 11 Feb, 2019 1 commit
  2. 04 Jan, 2019 1 commit
    • Peter Marshall's avatar
      [cpu-profiler] Reduce the size of inlining information · a0572f0b
      Peter Marshall authored
      Previously we stored the source position table, which stored a mapping
      of pc offsets to line numbers, and the inline_locations, which stored a
      mapping of pc offsets to stacks of {CodeEntry, line_number} pairs. This
      was slightly wasteful because we had two different tables which were
      both keyed on the pc offset and contained some overlapping information.
      
      This CL combines the two tables in a way. The source position table now
      maps a pc offset to a pair of {line_number, inlining_id}. If the
      inlining_id is valid, then it can be used to look up the inlining stack
      which is stored in inline_locations, but is now keyed by inlining_id
      rather than pc offset. This also has the nice effect of de-duplicating
      inline stacks which we previously duplicated.
      
      The new structure is similar to how this data is stored by the compiler,
      except that we convert 'source positions' (char offset in a file) into
      line numbers as we go, because we only care about attributing ticks to
      a given line.
      
      Also remove the helper RecordInliningInfo() as this is only actually
      used to add inline stacks by one caller (where it is now inlined). The
      other callers would always bail out or are only called from
      test-cpu-profiler.
      
      Remove AddInlineStack and replace it with SetInlineStacks which adds all
      of the stacks at once. We need to do it this way because the source pos
      table is passed into the constructor of CodeEntry, so we need to create
      it before the CodeEntry, but the inline stacks are not (they are part of
      rare_data which is not always present), so we need to add them after
      construction. Given that we calculate both the source pos table and the
      inline stacks before construction, it's just easier to add them all at
      once.
      
      Also add a print() method to CodeEntry to make future debugging easier
      as I'm constantly rewriting this locally.
      
      Bug: v8:8575, v8:7719, v8:7203
      
      Change-Id: I39324d6ea13d116d5da5d0a0d243cae76a749c79
      Reviewed-on: https://chromium-review.googlesource.com/c/1392195
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58554}
      a0572f0b
  3. 28 Nov, 2018 1 commit
  4. 27 Nov, 2018 1 commit
  5. 25 Nov, 2018 1 commit
  6. 12 Nov, 2018 1 commit
  7. 27 Jul, 2018 1 commit
    • Peter Marshall's avatar
      [cpu-profiler] Use instruction start as the key for the CodeMap · ba752ea4
      Peter Marshall authored
      Previously we used the start address of the AbstractCode object. This
      doesn't make sense for off-heap builtins, where the code isn't contained
      in the object itself. It also hides other potential problems - sometimes
      the sample.pc is inside the AbstractCode object header - this is
      never valid.
      
      There were a few changes necessary to make this happen:
        - Change the interface of CodeMoveEvent. Now 'to' and 'from' are both
          AbstractCode objects, which is nice because many users were taking
          'to' and adding the header offset to it to try and find the
          instruction start address. This isn't valid for off-heap builtins.
        - Fix a bug in CodeMap::MoveCode where we didn't update the CodeEntry
          object to reflect the new instruction_start.
        - Rename the 'start' field in all of the CodeEventRecord sub-classes
          to make it clear that this is the address of the first instruction.
        - Fix the confusion in RecordTickSample between 'tos' and 'pc' which
          caused pc_offset to be calculated incorrectly.
      
      Bug: v8:7983
      Change-Id: I3e9dddf74e4b2e96a5f031d216ef7008d6f184d1
      Reviewed-on: https://chromium-review.googlesource.com/1148457
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54749}
      ba752ea4
  8. 13 Jun, 2018 1 commit
  9. 24 May, 2018 2 commits
  10. 16 May, 2018 1 commit
    • Alexei Filippov's avatar
      [cpu-profiler] Eagerly delete not used CodeEntry'es · c6c28f7a
      Alexei Filippov authored
      Currently ProfilerListener holds all the CodeEntries it ever
      created during the profiling session. It is not capable of removing
      entries corresponding to the code objects discarded by GC as there's
      no such code event.
      
      However it is sometimes possible to tell if a code object was GCed.
      Hook up to the CodeMap code entry removal and if the entry has never
      been hit by a sample we can safely delete it.
      
      As a bonus the CodeEntryInfo size has been reduced on x64, which also
      saves 8 x <number of code entries> bytes.
      
      BUG=v8:7719
      
      Change-Id: I988bc5b59f3fba07157a9f472cbcf68596fcd969
      Reviewed-on: https://chromium-review.googlesource.com/1054346Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Alexei Filippov <alph@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53222}
      c6c28f7a
  11. 09 May, 2018 1 commit
  12. 07 May, 2018 1 commit
  13. 04 May, 2018 1 commit
  14. 18 Apr, 2018 1 commit
  15. 17 Apr, 2018 2 commits
  16. 14 Apr, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored
      The "Address" type is V8's general-purpose type for manipulating memory
      addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
      are undefined behavior except within the same array; since we generally
      don't operate within a C++ array, our general-purpose type shouldn't be
      a pointer type.
      
      Bug: v8:3770
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
      Reviewed-on: https://chromium-review.googlesource.com/988657
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  17. 12 Apr, 2018 1 commit
    • Peter Marshall's avatar
      [cpu-profiler] Fix bugs and add tests for JITLineInfoTable · 4feb5ce7
      Peter Marshall authored
      Looking up line numbers with the JITLineInfoTable would sometimes give
      wrong answers. Fix these bugs and add a cctest for this data structure.
      
      Also do some cleanup while we're here like inlining the (empty)
      constructor and destructor and removing the empty() method which is
      only used unnecessarily anyway, to make the contract of
      GetSourceLineNumber a bit clearer.
      
      Also rename the data structure to SourcePositionTable, because it
      doesn't just provide info for JIT code, but also bytecode, and 'Info'
      is pretty ambiguous.
      
      Bug: v8:7018
      Change-Id: I126581c844d85df6b2b3f80f2f5acbce01c16ba1
      Reviewed-on: https://chromium-review.googlesource.com/1006795Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52571}
      4feb5ce7
  18. 22 Mar, 2018 1 commit
  19. 09 Mar, 2018 1 commit
  20. 20 Feb, 2018 1 commit
  21. 05 Feb, 2018 2 commits
  22. 06 Dec, 2017 1 commit
  23. 19 Oct, 2017 1 commit
  24. 13 Oct, 2017 1 commit
  25. 22 Mar, 2017 1 commit
  26. 29 Sep, 2016 1 commit
  27. 22 Jun, 2016 1 commit
    • lpy's avatar
      [Reland] Refactor CpuProfiler. · 04f710ac
      lpy authored
      Currently CpuProfiler is a subclass of CodeEventListener, it listens code events
      from Logger, constructs and stores CodeEventsContainer. This patch is part of
      the effort to split the logic of CodeEventListener as ProfilerListener out of
      the profiling functionality logic in CpuProfiler. A ProfilerListener will listen
      to code events, construct code event to CodeEventsContainer and pass it to code
      event handler.
      
      The reason we refactor CpuProfiler is that eventually we want to move
      CpuProfiler as part of sampler library and code event listener should stay
      inside V8.
      
      Main changes:
      1. Refactored CpuProfiler into two parts, the CpuProfiler with profling
      functionality and the ProfilerListener listening to code events from Logger.
      2. Created CodeEventObserver and made CpuProfiler inherit from it.
      ProfilerListener will have a list of observers and call CodeEventHandler once a
      code event is created.
      3. Moved code entry list from CodeEntry to ProfilerListener.
      
      Minor changes:
      1. Moved static code entry as part of CodeEntry.
      2. Added ProfilerListener to Logger.
      
      BUG=v8:4789
      
      Committed: https://crrev.com/cb59fc1facc9b390e2c7544b4da56a4e0a9b3222
      Review-Url: https://codereview.chromium.org/2053523003
      Cr-Original-Commit-Position: refs/heads/master@{#37112}
      Cr-Commit-Position: refs/heads/master@{#37195}
      04f710ac
  28. 20 Jun, 2016 2 commits
    • lpy's avatar
      Revert of Refactor CpuProfiler. (patchset #13 id:240001 of... · d6be0bf6
      lpy authored
      Revert of Refactor CpuProfiler. (patchset #13 id:240001 of https://codereview.chromium.org/2053523003/ )
      
      Reason for revert:
      MIPS compilation error.
      
      Original issue's description:
      > Refactor CpuProfiler.
      >
      > Currently CpuProfiler is a subclass of CodeEventListener, it listens code events
      > from Logger, constructs and stores CodeEventsContainer. This patch is part of
      > the effort to split the logic of CodeEventListener as ProfilerListener out of
      > the profiling functionality logic in CpuProfiler. A ProfilerListener will listen
      > to code events, construct code event to CodeEventsContainer and pass it to code
      > event handler.
      >
      > The reason we refactor CpuProfiler is that eventually we want to move
      > CpuProfiler as part of sampler library and code event listener should stay
      > inside V8.
      >
      > Main changes:
      > 1. Refactored CpuProfiler into two parts, the CpuProfiler with profling
      > functionality and the ProfilerListener listening to code events from Logger.
      > 2. Created CodeEventObserver and made CpuProfiler inherit from it.
      > ProfilerListener will have a list of observers and call CodeEventHandler once a
      > code event is created.
      > 3. Moved code entry list from CodeEntry to ProfilerListener.
      >
      > Minor changes:
      > 1. Moved static code entry as part of CodeEntry.
      > 2. Added ProfilerListener to Logger.
      >
      > BUG=v8:4789
      >
      > Committed: https://crrev.com/cb59fc1facc9b390e2c7544b4da56a4e0a9b3222
      > Cr-Commit-Position: refs/heads/master@{#37112}
      
      TBR=alph@chromium.org,jochen@chromium.org,yangguo@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4789
      
      Review-Url: https://codereview.chromium.org/2079273003
      Cr-Commit-Position: refs/heads/master@{#37113}
      d6be0bf6
    • lpy's avatar
      Refactor CpuProfiler. · cb59fc1f
      lpy authored
      Currently CpuProfiler is a subclass of CodeEventListener, it listens code events
      from Logger, constructs and stores CodeEventsContainer. This patch is part of
      the effort to split the logic of CodeEventListener as ProfilerListener out of
      the profiling functionality logic in CpuProfiler. A ProfilerListener will listen
      to code events, construct code event to CodeEventsContainer and pass it to code
      event handler.
      
      The reason we refactor CpuProfiler is that eventually we want to move
      CpuProfiler as part of sampler library and code event listener should stay
      inside V8.
      
      Main changes:
      1. Refactored CpuProfiler into two parts, the CpuProfiler with profling
      functionality and the ProfilerListener listening to code events from Logger.
      2. Created CodeEventObserver and made CpuProfiler inherit from it.
      ProfilerListener will have a list of observers and call CodeEventHandler once a
      code event is created.
      3. Moved code entry list from CodeEntry to ProfilerListener.
      
      Minor changes:
      1. Moved static code entry as part of CodeEntry.
      2. Added ProfilerListener to Logger.
      
      BUG=v8:4789
      
      Review-Url: https://codereview.chromium.org/2053523003
      Cr-Commit-Position: refs/heads/master@{#37112}
      cb59fc1f