1. 28 Mar, 2019 2 commits
  2. 27 Mar, 2019 2 commits
  3. 25 Mar, 2019 1 commit
    • Benedikt Meurer's avatar
      [tracing] Improve tracing signals for compilation/optimization. · a2af7e11
      Benedikt Meurer authored
      This adds OBJECT/SNAPSHOT trace events for Script and SharedFunctionInfo
      objects, logging their creation with appropriate information to make
      sense of them.
      
      Based on that we introduces five flow events to model the optimized
      compilation via tracing in the "disabled-by-default-v8.compile" category:
      
        - "v8.optimizingCompile.start" logs the creation of the
          PipelineCompilationJob (for TurboFan JavaScript optimization)
          with the "function" argument referring to the trace event
          object created for the SharedFunctionInfo.
        - "v8.optimzingCompile.prepare" logs the preparation of the
          PipelineCompilationJob on the main thread, also carrying the
          "function" argument. This connects the flow event to the actual
          tracing duration event associated with the preparation phases.
        - "v8.optimizingCompile.execute" logs the (usually concurrent)
          optimization of the TurboFan graph (again with "function").
        - "v8.optimizingCompile.finalize" logs the main thread phase which
          finalizes the optimized code and eventually installs it (in case
          of success).
        - "v8.optimizingCompile.end" signals the end of the
          PipelineCompilationJob, which carries the "compilationInfo",
          that contains the interesting bits of the OptimizedCompilationInfo,
          specifically whether the compile was successfull and which functions
          were inlined for example.
      
      This also adds two instant events "V8.AbortOptimization" and
      "V8.RetryOptimization" in "disabled-by-default-v8.compile" category
      that are emitted when TurboFan cannot optimize a certain function.
      In case of "V8.RetryOptimization", TurboFan might be able to optimize
      it later, whereas "V8.AbortOptimization" permanently disables the
      optimization of a given function. The JSON representation of this is
      
      ```js
      {
        "pid": 256639,
        "tid": 256639,
        "ts": 6935411377801,
        "tts": 159116,
        "ph": "I",
        "cat": "disabled-by-default-v8.compile",
        "name": "V8.AbortOptimization",
        "dur": 0,
        "tdur": 0,
        "args": {
          "reason": "Function is too big to be optimized",
          "function": {
            "id_ref": "0x600000001",
            "scope": "v8::internal::SharedFunctionInfo"
          }
        }
      },
      ```
      
      where the "function" refers to a previously emitted SNAPSHOT for the
      function in question. In the trace viewer it will show up as instant
      event under "v8.optimizingCompile.prepare" in case of the relevant
      example where optimization is disabled due to reaching the bytecode
      limit (as in the JSON above), i.e. it'll look something like this
      
        https://i.paste.pics/aafc2de9df10ea8f5acc1a761d80f07b.png
      
      for the example highlighted in the recent blog post
      
        https://ponyfoo.com/articles/javascript-performance-pitfalls-v8
      
      that describes the optimization limit. The "v8.optimizingCompile.end"
      duration event will also carry this information as part of the
      "compilationInfo" object, but specifically for CI tools, etc. it might
      be a whole lot easier to just look for the "V8.AbortOptimization"
      instant event.
      
      Bug: v8:8598, v8:9039
      Tbr: ulan@chromium.org
      Doc: bit.ly/v8-tracing-signals
      Change-Id: Ic87ac336004690c65b6b15ad73bc6fbd4b5f12c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511483
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60448}
      a2af7e11
  4. 20 Mar, 2019 2 commits
    • Leszek Swirski's avatar
      Revert "V8 x64 backend doesn't emit ABI compliant stack frames" · 9f6ddb48
      Leszek Swirski authored
      This reverts commit 3cda21de.
      
      Reason for revert: Breaks the roll on Windows (see https://cr-buildbucket.appspot.com/build/8918477701097622400)
      
      Original change's description:
      > V8 x64 backend doesn't emit ABI compliant stack frames
      > 
      > On 64 bit Windows, the OS stack walking does not work because the V8 x64
      > backend doesn't emit unwinding info and also because it doesn't emit ABI
      > compliant stack frames. See
      > https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit
      > for more details.
      > 
      > This problem can be fixed by observing that V8 frames usually all have the same
      > prolog and epilog:
      > 
      > push rbp,
      > mov rbp, rsp
      > ...
      > pop rbp
      > ret N
      > 
      > and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows
      > should walk through V8 frames. Furthermore, since V8 Code objects are all
      > allocated in the same code-range for an Isolate, it is possible to register a
      > single PDATA/XDATA entry to cover stack walking for all the code generated
      > inside that code-range.
      > 
      > This PR contains changes required to enable stack walking on Win64:
      > 
      > EmbeddedFileWriter now adds assembler directives to the builtins
      > snapshot source file (embedded.cc) to emit additional entries in the .pdata and
      > in the .xdata section of the V8 executable. This takes care of stack walking
      > for embedded builtins. (The case of non-embedded builtins is not supported).
      > The x64 Assembler has been modified to collect the information required to emit
      > this unwind info for builtins.
      > 
      > Stack walking for jitted code is handled is Isolate.cpp, by registering
      > dynamically PDATA/XDATA for the whole code-range address space every time a new
      > Isolate is initialized, and by unregistering them when the Isolate is
      > destroyed.
      > 
      > Stack walking for WASM jitted code is handled is the same way in
      > wasm::NativeModule (wasm/wasm-code-manager.cpp).
      > 
      > It is important to note that Crashpad and Breakpad are already registering
      > PDATA/XDATA to manage and report unhandled exceptions (but not for embedded
      > builtins). Since it is not possible to register multiple PDATA entries for the
      > same address range, a new function is added to the V8 API:
      > SetUnhandledExceptionCallback() can be used by an embedder to register its own
      > unhandled exception handler for exceptions that arise in v8-generated code.
      > V8 embedders should be modified accordingly (code for this is in a separate PR
      > in the Chromium repository:
      > https://chromium-review.googlesource.com/c/chromium/src/+/1474703).
      > 
      > All these changes are experimental, behind:
      > 
      > the 'v8_win64_unwinding_info' build flag, and
      > the '--win64-unwinding-info' runtime flag.
      > 
      > Bug: v8:3598
      > Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#60330}
      
      TBR=bbudge@chromium.org,ulan@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,gdeepti@chromium.org,jgruber@chromium.org,paolosev@microsoft.com
      
      Change-Id: If8470da94c58df8c800cbe8887f9f86236e43353
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:3598
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532321Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60372}
      9f6ddb48
    • Tom Anderson's avatar
      Fix V8 snapshot build for 32-bit Win/cross · 701eb086
      Tom Anderson authored
      This CL includes a revert of [1] with thakis@'s proposed fix at [2].  Verified a
      build with the below gn args works on Linux:
      
      target_os = "win"
      target_cpu = "x86"
      is_debug = false
      is_official_build = true
      is_component_build = false
      use_goma = true
      enable_nacl = false
      use_custom_libcxx = true
      
      [1] https://chromium.googlesource.com/v8/v8.git/+/93ee541417b6f5904072c0ecdfc6fc041811b489
      [2] https://bugs.chromium.org/p/chromium/issues/detail?id=942347#c2
      
      BUG=chromium:942347
      R=machenbach
      CC=thakis
      
      Change-Id: I34f5744a9f600efbc075f4b5ba8d1c66bff46ae6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529250
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Auto-Submit: Thomas Anderson <thomasanderson@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60349}
      701eb086
  5. 19 Mar, 2019 3 commits
    • Milad Farazmand's avatar
      PPC: adding torque debug info for AIX on PPC · a353f453
      Milad Farazmand authored
      Due to ppc having a fixed 4 byte instruction length, changing
      ByteChunk length from 8 to 4 bytes will fix any padding issues
      while generating the "embed.S" file.
      
      Change-Id: Ide799908effd88d5387e97627917b095fcc3051c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1524720
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60337}
      a353f453
    • Paolo Severini's avatar
      V8 x64 backend doesn't emit ABI compliant stack frames · 3cda21de
      Paolo Severini authored
      On 64 bit Windows, the OS stack walking does not work because the V8 x64
      backend doesn't emit unwinding info and also because it doesn't emit ABI
      compliant stack frames. See
      https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit
      for more details.
      
      This problem can be fixed by observing that V8 frames usually all have the same
      prolog and epilog:
      
      push rbp,
      mov rbp, rsp
      ...
      pop rbp
      ret N
      
      and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows
      should walk through V8 frames. Furthermore, since V8 Code objects are all
      allocated in the same code-range for an Isolate, it is possible to register a
      single PDATA/XDATA entry to cover stack walking for all the code generated
      inside that code-range.
      
      This PR contains changes required to enable stack walking on Win64:
      
      EmbeddedFileWriter now adds assembler directives to the builtins
      snapshot source file (embedded.cc) to emit additional entries in the .pdata and
      in the .xdata section of the V8 executable. This takes care of stack walking
      for embedded builtins. (The case of non-embedded builtins is not supported).
      The x64 Assembler has been modified to collect the information required to emit
      this unwind info for builtins.
      
      Stack walking for jitted code is handled is Isolate.cpp, by registering
      dynamically PDATA/XDATA for the whole code-range address space every time a new
      Isolate is initialized, and by unregistering them when the Isolate is
      destroyed.
      
      Stack walking for WASM jitted code is handled is the same way in
      wasm::NativeModule (wasm/wasm-code-manager.cpp).
      
      It is important to note that Crashpad and Breakpad are already registering
      PDATA/XDATA to manage and report unhandled exceptions (but not for embedded
      builtins). Since it is not possible to register multiple PDATA entries for the
      same address range, a new function is added to the V8 API:
      SetUnhandledExceptionCallback() can be used by an embedder to register its own
      unhandled exception handler for exceptions that arise in v8-generated code.
      V8 embedders should be modified accordingly (code for this is in a separate PR
      in the Chromium repository:
      https://chromium-review.googlesource.com/c/chromium/src/+/1474703).
      
      All these changes are experimental, behind:
      
      the 'v8_win64_unwinding_info' build flag, and
      the '--win64-unwinding-info' runtime flag.
      
      Bug: v8:3598
      Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#60330}
      3cda21de
    • Igor Sheludko's avatar
      [ptr-compr][ubsan] Use [Read/Write]UnalignedValue for unaligned fields · 0188634e
      Igor Sheludko authored
      When pointer compression is enabled the [u]intptr_t and double fields are
      only kTaggedSize aligned so in order to avoid undefined behavior in C++ code
      we have to access these values in an unaligned pointer friendly way although
      both x64 and arm64 architectures (where pointer compression is supported)
      allow unaligned access.
      
      These changes will be removed once v8:8875 is fixed and all the
      kSystemPointerSize fields are properly aligned.
      
      Bug: v8:7703
      Change-Id: I4df477cbdeab806303bb4f675d52b61c06342c8e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1528996
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60321}
      0188634e
  6. 18 Mar, 2019 1 commit
  7. 13 Mar, 2019 2 commits
  8. 12 Mar, 2019 1 commit
  9. 07 Mar, 2019 1 commit
  10. 06 Mar, 2019 1 commit
  11. 01 Mar, 2019 1 commit
  12. 28 Feb, 2019 2 commits
  13. 27 Feb, 2019 1 commit
  14. 25 Feb, 2019 2 commits
  15. 18 Feb, 2019 1 commit
    • Mike Stanton's avatar
      Reland "[Torque] Add source positions for Torque files" · b08c6947
      Mike Stanton authored
      Reason for revert/reland: UBSan complained of unaligned reads.
      
      To improve the Torque debugging experience, we can add source positions
      for each line. This information is carried through the generated
      CSA code (in <output directory>/gen/torque-generated/*.cc) and
      embedded as SourcePositions in the Code object.
      
      At snapshot time, these SourcePositions are stripped from the Code
      object and turned into platform-appropriate line number debug
      information.
      
      At this time on Linux, you'll need to build with "is_clang=false"
      in order to use GCC, because crucial steps are missing in Clang's
      ability to convey the information into the binary successfully.
      
      This CL also introduces a flag to control the existing source
      information in CSA code. --enable-source-at-csa-bind is now set
      to false by default because it's a bit confusing to "hop" between
      source lines in .TQ files and in .CC files. I expect to continue
      making adjustments there, as I want to provide helpful
      debugging aids at the CSA level as well as the Torque level.
      The current configuration prioritizes Torque.
      
      TBR=tebbi@chromium.org
      
      Bug: v8:8418
      Change-Id: Idb80467d3679ec2361386fe9b67597b93d7f72cf
      Reviewed-on: https://chromium-review.googlesource.com/c/1475763Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59657}
      b08c6947
  16. 15 Feb, 2019 1 commit
  17. 14 Feb, 2019 2 commits
  18. 13 Feb, 2019 1 commit
  19. 08 Feb, 2019 6 commits
  20. 07 Feb, 2019 3 commits
  21. 06 Feb, 2019 4 commits