1. 29 Apr, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Use Vector::begin instead of Vector::start · 4b0f9c85
      Clemens Hammacher authored
      Our {Vector} template provides both {start} and {begin} methods. They
      return exactly the same value. Since the {begin} method is needed for
      iteration, and is also what standard containers provide, this CL
      switches all uses of the {start} method to use {begin} instead.
      
      Patchset 1 was auto-generated by using this clang AST matcher:
          callExpr(
              callee(
                cxxMethodDecl(
                  hasName("start"),
                  ofClass(hasName("v8::internal::Vector")))
              ),
              argumentCountIs(0))
      
      Patchset 2 was created by running clang-format. Patchset 3 then
      removes the now unused {Vector::start} method.
      
      R=jkummerow@chromium.org
      TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org
      
      Bug: v8:9183
      Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61081}
      4b0f9c85
  2. 05 Feb, 2019 1 commit
  3. 22 Jan, 2019 1 commit
  4. 26 Dec, 2018 1 commit
  5. 04 Dec, 2018 1 commit
  6. 28 Nov, 2018 1 commit
  7. 27 Nov, 2018 1 commit
  8. 25 Nov, 2018 1 commit
  9. 16 Nov, 2018 1 commit
  10. 12 Nov, 2018 1 commit
  11. 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
  12. 16 Jul, 2018 1 commit
  13. 26 Jun, 2018 1 commit
  14. 14 May, 2018 1 commit
  15. 09 May, 2018 2 commits
  16. 08 May, 2018 1 commit
  17. 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
  18. 05 Apr, 2018 1 commit
    • jgruber's avatar
      Rename Code::instruction_{start,end,size} functions · 7b29fe43
      jgruber authored
      In order to clarify the difference between, e.g., InstructionStart and
      instruction_start, rename as follows:
      
      Code::instruction_start -> raw_instruction_start
      Code::instruction_end   -> raw_instruction_end
      Code::instruction_size  -> raw_instruction_size
      
      The difference between the camel-case and raw_* function families is
      in how they handle off-heap-trampoline Code objects. For example, when
      called on an off-heap-trampoline: raw_instruction_start returns the
      trampoline's entry point, while InstructionStart returns the off-heap
      code's entry point (located in the .text section of the binary).
      
      Some callsites were updated to call the camel-case function family as
      appropriate.
      
      Bug: v8:6666
      Change-Id: I4a572f47c2d161a853599d7c17879e263b0d1a87
      Reviewed-on: https://chromium-review.googlesource.com/997532
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52387}
      7b29fe43
  19. 22 Mar, 2018 1 commit
  20. 09 Mar, 2018 1 commit
  21. 20 Feb, 2018 1 commit
  22. 19 Feb, 2018 1 commit
  23. 06 Feb, 2018 1 commit
  24. 05 Feb, 2018 1 commit
  25. 02 Dec, 2017 1 commit
    • Mathias Bynens's avatar
      Normalize casing of hexadecimal digits · 822be9b2
      Mathias Bynens authored
      This patch normalizes the casing of hexadecimal digits in escape
      sequences of the form `\xNN` and integer literals of the form
      `0xNNNN`.
      
      Previously, the V8 code base used an inconsistent mixture of uppercase
      and lowercase.
      
      Google’s C++ style guide uses uppercase in its examples:
      https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters
      
      Moreover, uppercase letters more clearly stand out from the lowercase
      `x` (or `u`) characters at the start, as well as lowercase letters
      elsewhere in strings.
      
      BUG=v8:7109
      TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
      NOPRESUBMIT=true
      
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
      Reviewed-on: https://chromium-review.googlesource.com/804294
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49810}
      822be9b2
  26. 17 Nov, 2017 1 commit
  27. 18 Oct, 2017 1 commit
  28. 13 Oct, 2017 1 commit
  29. 12 Sep, 2017 1 commit
  30. 11 Sep, 2017 1 commit
  31. 30 Aug, 2017 1 commit
  32. 03 Aug, 2017 1 commit
  33. 12 Apr, 2017 1 commit
  34. 04 Apr, 2017 1 commit
    • pierre.langlois's avatar
      [perf-prof] Fix erroneous code offsets in unwinding info · 21f064fc
      pierre.langlois authored
      The unwinding information we emit wrongly encodes code locations as relative
      offsets. If we look at the .eh_frame section of shared object generated by "perf
      inject" using "objdump -g":
      
      ~~~
      00000000 0000000000000018 00000000 CIE
      (snip)
      0000001c 0000000000000028 00000020 FDE cie=00000000 pc=fffffffffffffee8..00000000000017f8
      (snip)
      00000048 ZERO terminator
      ~~~
      
      We can see the range that the FDE entry covers is incorrect, it should point to
      where the .text section is, at address 0x40 on a 64-bit architecture.
      
      The reason for this was that the PerfJitLogger logs a code size that is
      different from the one we've used when encoding the unwinding information. The
      logger will ignore the safepoint table while the unwinding info assumes it is
      part of the code.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2790403002
      Cr-Commit-Position: refs/heads/master@{#44378}
      21f064fc
  35. 03 Apr, 2017 1 commit
  36. 12 Dec, 2016 1 commit
  37. 09 Dec, 2016 1 commit
    • yangguo's avatar
      [perf-prof] fix crash when logging. · 75f52005
      yangguo authored
      Logging for --perf-prof is not GC safe. Now, we are going to
      emit source position info for optimized code when we are
      profiling, logging, or debugging, and under the same condition,
      pre-compute the line ends array for line number computation.
      
      R=tebbi@chromium.org
      BUG=v8:5730
      
      Review-Url: https://codereview.chromium.org/2562973002
      Cr-Commit-Position: refs/heads/master@{#41619}
      75f52005
  38. 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
  39. 11 Nov, 2016 1 commit