Skip to content

V
V8
Switch branch/tag
  1. 26 Jul, 2017 1 commit
  3. 25 Jul, 2017 1 commit
  5. 18 Jul, 2017 1 commit
  7. 10 Jul, 2017 1 commit
  9. 22 Jun, 2017 1 commit
  11. 21 Jun, 2017 1 commit
  13. 30 May, 2017 1 commit
  15. 07 Apr, 2017 1 commit
  17. 06 Apr, 2017 1 commit
  19. 24 Mar, 2017 1 commit
  21. 22 Mar, 2017 1 commit
  23. 10 Mar, 2017 1 commit
  25. 06 Mar, 2017 1 commit
  27. 20 Feb, 2017 1 commit
  29. 02 Feb, 2017 1 commit
  31. 23 Jan, 2017 1 commit
  33. 20 Jan, 2017 2 commits
  35. 11 Jan, 2017 1 commit
    • clemensh's avatar
      [wasm] Introduce WasmToInterpreterFrame · 81700ddf
      clemensh authored 
      and rename WasmFrame to WasmCompiledFrame.
The WasmToInterpreterFrames are not used yet; this will follow in a
follow-up CL (see tracking bug for the overall picture).
Those frames will represent frames for WASM_TO_INTERPRETER stubs, which
call from wasm code to the wasm interpreter, implemented in C++.
They will support the Summarize method to inspect the stack frames in
the wasm interpreter.

R=yangguo@chromium.org, titzer@chromium.org
BUG=v8:5822

Review-Url: https://codereview.chromium.org/2623773004
Cr-Commit-Position: refs/heads/master@{#42213}
      81700ddf
  37. 03 Jan, 2017 1 commit
    • leszeks's avatar
      [profiler] Log both code and bytecode in heap SFI traversal · b8f93dfe
      leszeks authored 
      The heap traversal for SFI code objects when logging compiled functions
was previously accessing the abstract code of an SFI, logging its
bytecode if it exists or code object otherwise. However, there are some
(rare) cases where an SFI has both bytecode and a non-interpreter code
object -- for example, after baseline tier-up -- in which case we want
to log both, as both could be executing (at different points on the
stack).

BUG=v8:5758

Review-Url: https://codereview.chromium.org/2603333002
Cr-Commit-Position: refs/heads/master@{#42025}
      b8f93dfe
  39. 21 Dec, 2016 1 commit
  41. 24 Nov, 2016 1 commit
    • cbruni's avatar
      [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters · 244dd002
      cbruni authored 
      RuntimeTimerScopes always subtract their own time from the parent timer's
counter to properly account for the own time. Once a scope is destructed it
adds it own timer to the current active counter. However, if the current
counter is changed with CorrectCurrentCounterId we will attribute all the
subtimers to the previous counter, and add the own time to the new counter.
This way it is possible to end up with negative times in certain counters but
the overall would still be correct.

BUG=

Review-Url: https://codereview.chromium.org/2511093002
Cr-Commit-Position: refs/heads/master@{#41254}
      244dd002
  43. 23 Nov, 2016 2 commits
  45. 14 Nov, 2016 1 commit
    • tebbi's avatar
      This CL enables precise source positions for all V8 compilers. It merges... · c3a6ca68
      tebbi authored 
      This CL enables precise source positions for all V8 compilers. It merges compiler::SourcePosition and internal::SourcePosition to a single class used throughout the codebase. The new internal::SourcePosition instances store an id identifying an inlined function in addition to a script offset.
SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id:
 - The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray
 - The SourcePosition of the inlining. Recursively, this yields the full inlining stack.
Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions().

If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function.
So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer.

All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file.

At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts.

I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases.

The following additional changes were necessary:
 - The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id.
 - The class HPositionInfo was effectively dead code and is now removed.
 - SourcePosition has new printing and information facilities, including computing a full inlining stack.
 - I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file.
 - I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions().
 - I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids.
 - Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already).

BUG=v8:5432

Review-Url: https://codereview.chromium.org/2451853002
Cr-Commit-Position: refs/heads/master@{#40975}
      c3a6ca68
  47. 04 Nov, 2016 1 commit
  49. 03 Nov, 2016 2 commits
  51. 27 Oct, 2016 1 commit
  53. 24 Oct, 2016 1 commit
  55. 21 Oct, 2016 1 commit
  57. 20 Oct, 2016 2 commits
  59. 14 Oct, 2016 1 commit
  61. 17 Aug, 2016 1 commit
    • rmcilroy's avatar
      Avoid accessing Isolate in source position logging. · b8b4a443
      rmcilroy authored 
      Now that all backends use the source position builder to record source
positions, simplify the code line logging events to take a source
position table on code creation. This means that the source position
table builder no longer needs to access the isolate until the table is
generated. This is required for off-thread bytecode generation.

BUG=v8:5203

Review-Url: https://codereview.chromium.org/2248673002
Cr-Commit-Position: refs/heads/master@{#38676}
      b8b4a443
  63. 11 Aug, 2016 1 commit
  65. 10 Aug, 2016 1 commit
  67. 28 Jul, 2016 1 commit
  69. 25 Jul, 2016 1 commit
  71. 12 Jul, 2016 1 commit