Skip to content

V
V8
Switch branch/tag
  1. 14 May, 2018 1 commit
  3. 09 May, 2018 2 commits
  5. 08 May, 2018 1 commit
  7. 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
  9. 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
  11. 22 Mar, 2018 1 commit
  13. 09 Mar, 2018 1 commit
  15. 20 Feb, 2018 1 commit
  17. 19 Feb, 2018 1 commit
  19. 06 Feb, 2018 1 commit
  21. 05 Feb, 2018 1 commit
  23. 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
  25. 17 Nov, 2017 1 commit
  27. 18 Oct, 2017 1 commit
  29. 13 Oct, 2017 1 commit
  31. 12 Sep, 2017 1 commit
  33. 11 Sep, 2017 1 commit
  35. 30 Aug, 2017 1 commit
  37. 03 Aug, 2017 1 commit
  39. 12 Apr, 2017 1 commit
  41. 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
  43. 03 Apr, 2017 1 commit
  45. 12 Dec, 2016 1 commit
  47. 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
  49. 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
  51. 11 Nov, 2016 1 commit
  53. 25 Jul, 2016 1 commit
  55. 14 Jul, 2016 1 commit
    • ssanfilippo's avatar
      Reland Implement .eh_frame writer and disassembler. · a91dc7cd
      ssanfilippo authored 
      Original commit message:

  Also, CodeGenerator::MakeCodeEpilogue now accepts an optional pointer
  to a EhFrameWriter and will attach unwinding information to the code
  object when passed one.

Reason for reverting:

  The STATIC_CONST_MEMBER_DEFINITION in eh-frame-writer-unittest.cc
  causes a compiler error on V8 Win64 - clang buildbot.

  Removing that bit.

BUG=v8:4899
LOG=N

Review-Url: https://codereview.chromium.org/2023503002
Cr-Commit-Position: refs/heads/master@{#37754}
      a91dc7cd
  57. 13 Jul, 2016 2 commits
  59. 12 Jul, 2016 2 commits
  61. 29 Jun, 2016 1 commit
  63. 27 Jun, 2016 1 commit
    • ssanfilippo's avatar
      This commit is the first step towards emitting unwinding information in · 7d073b03
      ssanfilippo authored 
      the .eh_frame format as part of the jitdump generated when
FLAG_perf_prof is enabled. The final goal is allowing precise unwinding
of callchains that include JITted code when profiling V8 using perf.

Unwinding information is stored in the body of code objects after the
code itself, prefixed with its length and aligned to a 8-byte boundary.
A boolean flag in the header signals its presence, resulting in zero
memory overhead when the generation of unwinding info is disabled or
no such information was attached to the code object.

A new jitdump record type (with id 4) is introduced for specifying
optional unwinding information for code load records. The EhFrameHdr
struct is also introduced, together with a constructor to initialise it
from the associated code object.

At this stage no unwinding information is written to the jitdump, but
the infrastructure for doing so is ready in place.

BUG=v8:4899
LOG=N

Review-Url: https://codereview.chromium.org/1993653003
Cr-Commit-Position: refs/heads/master@{#37296}
      7d073b03
  65. 30 Mar, 2016 1 commit
  67. 29 Mar, 2016 2 commits
    • jarin's avatar
      Linux perf support - fix debug info. · e11b5f7a
      jarin authored 
      This fixes support for debug info in perf. Thanks to Stephane Eranian for
identifying the problem - debug info event has to be emitted before the
code load event. It also seems that perf does not yet support the shorthand
for repeated source files in the debug info entry ("\xff\0"), so I changed
it to always write the script name.

Review URL: https://codereview.chromium.org/1843563002

Cr-Commit-Position: refs/heads/master@{#35092}
      e11b5f7a
    • jarin's avatar
      Linux perf integration with the new support for JIT. · 82e95f59
      jarin authored 
      Difference from --perf-basic-prof:
- correctly attributes samples when code space gets reused (when unused code object dies and a new code objects is allocated at the same place).
- outputs compiled machine code for instruction-level profile.

Just like --perf-basic-prof, the file writer is not synchronized (even worse, there is a per-isolate file handle), so we will run into trouble with multiple isolates. However, this patch is still an improvement on --perf-basic-prof, and it should be fine to replace ll-prof.

The patch also introduces experimental support for debug info, but it does not seem to be picked by the perf tool.

Usage:

You need the perf tool from Linux kernel >4.5. Then run:

$ perf record -k mono d8 --perf-prof <your JS file>
$ perf inject -j -i perf.data -o perf.data.jitted
$ perf report -i perf.data.jitted

Some explanations:
The "-k mono" switch from "perf record" tells the perf tool to use the monotonic clock for perf sample timestamping. The "perf inject -j" command injects the collected code events into the perf data file, writing the output into perf.data.jitted. The perf report command then creates the report.

Review URL: https://codereview.chromium.org/1809203007

Cr-Commit-Position: refs/heads/master@{#35091}
      82e95f59
  69. 29 May, 2015 1 commit
  71. 30 Jan, 2015 1 commit