Skip to content

V
V8
Switch branch/tag
  1. 03 Jun, 2020 2 commits
  3. 02 Jun, 2020 2 commits
    • George Wort's avatar
      [turbolizer] Display live range uses · 7c0c5286
      George Wort authored 
      Display UsePositions in the intervals
in live ranges in turbolizer.

Uses are shown as vertical red lines.

Bug: v8:7327
Change-Id: Iab8d08989b9113d1b7d393252de5988e8b25b8de
Notry: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2224215
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68102}
      7c0c5286
    • Daniel Bevenius's avatar
      [tools] Add error handling to no_arg_cmd · fcac59ad
      Daniel Bevenius authored 
      Currently, it can be little difficult to understand why a command in
lldb-commands.py stops working. For example, at the moment running the
jlh command results in an empty line:

$ lldb --one-line "command script import ../../tools/lldb_commands.py" \
     v8_hello_world
(lldb) br s -f hello-world.cc -l 49
(lldb) jlh script

(lldb)

With this commit this would instead display the following error message:

(lldb) jlh script
Failed to evaluate command
_v8_internal_Print_Object(*(v8::internal::Object**)(*(void*)(script))) :
error: cannot cast from type 'v8::Local<v8::Script>' to pointer type
'void *'

The output is really only two lines but I've wrapped the lines here so
they don't exceed the 72 column width. I'll follow up with a commit to
fix the issue reported.

Change-Id: I634a412b616dad7cadd74dce36418d27c1997777
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083477Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68093}
      fcac59ad
  5. 01 Jun, 2020 1 commit
  7. 28 May, 2020 2 commits
  9. 27 May, 2020 1 commit
    • George Wort's avatar
      [turbolizer] Display live ranges with sequences · 0282737d
      George Wort authored 
      Display register allocation live ranges alongside sequences in
turbolizer.

The existing --trace-turbo flag now also outputs the register
allocation data as part of the json file alongside the
instruction sequence data that is already produced before and
after register allocation is performed. This data includes live
range intervals for each virtual and fixed register and the state
of their assignments.

This json data can now be displayed in turbolizer alongside the
instruction sequences. The information is presented as a grid,
with each grid cell representing a LifeTimePosition of a certain
virtual register, determined by the column and row indices
respectively. Each LifeTimePosition is shown to be part of an
instruction id which itself is shown to be part of a block id.
Each interval is shown as a coloured rectangle positioned over
the relevant cells, and displaying text to indicate the state of
their assignment.

The Resizer object has been extended to allow the grid's html
panel to be varied in size in the same manner that the left and
right panels can be. The size of the grid itself must also be
adjusted whenever the div container changes size.

The RangeView class is introduced and is created and held by the
single SequenceView object used to display the
InstructionSequence data before and after register allocation.
A checkbox allows the user to show/hide the range view, this is
disabled when register allocation data is not provided or more
than 249 instructions are in the sequence. The latter being
required due to the css grid-row-col limit of 1000 alond with
helping alleviate performance issues. The SequenceView object
tracks the phase index currently selected as well as whether or
not it is currently being shown. This ensures that the RangeView
is not hidden and shown when switching between before and after
register allocation, allowing for a smoother transition between
the two. The scroll position is also saved and restored for
convenience.

The data about the instruction sequence required for the display
is held by the RangeView object and reset whenever a new
instruction sequence is shown. The grid div must sync its scroll
with the headers and row labels so as to ensure a consistent
view. The register allocation data is extracted from the json,
with each register row showing all intervals within the relevant
ranges. When the view is switched between before and after
register allocation, the relevant intervals are swapped in.

Bug: v8:7327
Notry: true
Change-Id: I183535a2410a7d663382f387199885250fb98691
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184232Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68019}
      0282737d
  11. 25 May, 2020 3 commits
  13. 21 May, 2020 1 commit
    • Seth Brenith's avatar
      [diagnostics] Support --turbo-profiling for builtins · 18c73676
      Seth Brenith authored 
      Currently, if d8 is run with the --turbo-profiling flag, it prints info
about every TurboFan-compiled function. This info includes the number of
times that each basic block in the function was run. It also includes
text representations of the function's schedule and code, so that the
person reading the output can associate counters with blocks of code.

The data about each function is currently stored in a
BasicBlockProfiler::Data instance, which is attached to a list owned by
the singleton BasicBlockProfiler. Each Data contains an
std::vector<uint32_t> which represents how many times each block in the
function has executed. The generated code for each block uses a raw
pointer into the storage of that vector to implement incrementing the
counter.

With this change, if you compile with v8_enable_builtins_profiling and
then run with --turbo-profiling, d8 will print that same info about
builtins too.

In order to generate code that can survive being serialized to a
snapshot and reloaded, this change uses counters in the JS heap instead
of a std::vector outside the JS heap. The steps for instrumentation are
as follows:

1. Between scheduling and instruction selection, add code to increment
   the counter for each block. The counters array doesn't yet exist at
   this point, and allocation is disallowed, so at this point the code
   refers to a special marker value.
2. During finalization of the code, allocate a BasicBlockProfilingData
   object on the JS heap containing data equivalent to what is stored in
   BasicBlockProfiler::Data. This includes a ByteArray that is big
   enough to store the counters for each block.
3. Patch the reference in the BuiltinsConstantsTableBuilder so that
   instead of referring to the marker object, it now refers to this
   ByteArray. Also add the BasicBlockProfilingData object to a list that
   is attached to the heap roots so it can be easily accessed for
   printing.

Because these steps include modifying the BuiltinsConstantsTableBuilder,
this procedure is only applicable to builtins. Runtime-generated code
still uses raw pointers into std::vector instances. In order to keep
divergence between these code paths to a minimum, most work is done
referring to instances of BasicBlockProfiler::Data (the C++ class), and
functions are provided to copy back and forth between that type and
BasicBlockProfilingData (the JS heap object).

This change is intended only to make --turbo-profiling work consistently
on more kinds of functions, but with some further work, this data could
form the basis for:
- code coverage info for fuzzers, and/or
- hot-path info for profile-guided optimization.

Bug: v8:10470, v8:9119
Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67944}
      18c73676
  15. 18 May, 2020 1 commit
  17. 15 May, 2020 1 commit
  19. 14 May, 2020 2 commits
  21. 13 May, 2020 3 commits
  23. 12 May, 2020 5 commits
  25. 11 May, 2020 1 commit
  27. 08 May, 2020 2 commits
  29. 07 May, 2020 1 commit
  31. 06 May, 2020 5 commits
  33. 05 May, 2020 1 commit
  35. 04 May, 2020 2 commits
    • Tobias Tebbi's avatar
      [torque] improve GC visitors · f1400e43
      Tobias Tebbi authored 
      Summary of changes:

- GC visitors no longer rely on superclass visitors, but instead visit
  everything themselves. This enables generating better code.
- Try to match simple body descriptors to reduce the amount of generated
  code.
- Turn SizeFor(instance) into an AllocatedSize() method.
- Remove the special handling of resizable object sizes from Torque
  and instead overwrite AllocatedSize in classes that need special
  handling in C++.
- Split the visitor id lists depending on whether the class has pointer
  fields.
- Turn Torque-generated body descriptors into an .inc file to
  simplify includes.
- Fix generated size functions to properly align the size.
- Generate GC visitors (and C++ class definitions) for all string
  classes and FixedArray, WeakFixedArray, and WeakArrayList.
- Store generated instance types in Torque class types. This is only
  used to determine if a type has a single instance type in this CL.

Bug: v8:7793
Change-Id: I4d362e96b047c305bd6d065247734957b8958c42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110014
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67542}
      f1400e43
    • Jakob Gruber's avatar
      [test] Add stress_snapshot test variant · fe8ff5f1
      Jakob Gruber authored 
      This variant passes the --stress-snapshot d8 flag. There's a large
initial list of skips, these should be removed as issues are fixed
over time. The variant is currently not enabled on any bots.

Bug: v8:10416
Change-Id: I80aea80600c51b2f5d28b8ec8a09ff0ba2ebaa7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2179002
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67536}
      fe8ff5f1
  37. 01 May, 2020 1 commit
  39. 28 Apr, 2020 2 commits
  41. 25 Apr, 2020 1 commit