1. 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
  2. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  3. 23 May, 2019 2 commits
  4. 11 Dec, 2018 1 commit
  5. 02 May, 2018 1 commit
    • jgruber's avatar
      Reland: [builtins] Patch self-references in constants table · ab9e0124
      jgruber authored
      Original CL: https://crrev.com/c/1018468
      
      During code generation, we generate self-references (i.e. references to
      the Code object currently being generated) as references to a temporary
      handle. When the final Code object has been allocated, the handle's
      location is fixed up and RelocInfo iteration fixes up all references
      embedded in the generated code.
      
      This adds support for this mechanism to the builtins constants table
      builder. CodeObject() is now a new handle pointing to a dedicated
      self-reference marker in order to distinguish between self-references
      and references to undefined. In Factory::NewCode, we patch up
      the constants table.
      
      TBR=yangguo@chromium.org,mlippautz@chromium.org
      
      Bug: v8:6666
      Change-Id: I3fa422c57de99c9851dc7a86394a8387c7c2b397
      Reviewed-on: https://chromium-review.googlesource.com/1039366
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52916}
      ab9e0124
  6. 27 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[builtins] Patch self-references in constants table" · 77d90890
      Michael Achenbach authored
      This reverts commit 6379e2a4.
      
      Reason for revert:
      https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Win64%2F23855%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2Fmkgrokdump%2F0
      
      Original change's description:
      > [builtins] Patch self-references in constants table
      > 
      > During code generation, we generate self-references (i.e. references to
      > the Code object currently being generated) as references to a temporary
      > handle. When the final Code object has been allocated, the handle's
      > location is fixed up and RelocInfo iteration fixes up all references
      > embedded in the generated code.
      > 
      > This adds support for this mechanism to the builtins constants table
      > builder. CodeObject() is now a new handle pointing to a dedicated
      > self-reference marker in order to distinguish between self-references
      > and references to undefined. In Factory::NewCode, we patch up
      > the constants table.
      > 
      > Bug: v8:6666
      > Change-Id: If74ed91bb1c3b8abb20ff2f0a87d1bcd9a1b0511
      > Reviewed-on: https://chromium-review.googlesource.com/1018468
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52854}
      
      TBR=yangguo@chromium.org,mlippautz@chromium.org,jgruber@chromium.org
      
      Change-Id: I8cf8c4b43f51285ea913c6c8fdd339bd9ea645df
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6666
      Reviewed-on: https://chromium-review.googlesource.com/1033092Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52856}
      77d90890
    • jgruber's avatar
      [builtins] Patch self-references in constants table · 6379e2a4
      jgruber authored
      During code generation, we generate self-references (i.e. references to
      the Code object currently being generated) as references to a temporary
      handle. When the final Code object has been allocated, the handle's
      location is fixed up and RelocInfo iteration fixes up all references
      embedded in the generated code.
      
      This adds support for this mechanism to the builtins constants table
      builder. CodeObject() is now a new handle pointing to a dedicated
      self-reference marker in order to distinguish between self-references
      and references to undefined. In Factory::NewCode, we patch up
      the constants table.
      
      Bug: v8:6666
      Change-Id: If74ed91bb1c3b8abb20ff2f0a87d1bcd9a1b0511
      Reviewed-on: https://chromium-review.googlesource.com/1018468
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52854}
      6379e2a4
  7. 22 Mar, 2018 1 commit
    • jgruber's avatar
      Reland "[builtins] Load external references from the external-reference-table" · 0031724f
      jgruber authored
      This is a reland of 9afde91b
      
      Original change's description:
      > [builtins] Load external references from the external-reference-table
      >
      > Off-heap code cannot embed external references. With this CL, we load
      > from the external reference table (reached through the root pointer)
      > instead.
      >
      > In a follow-up, the table could be stored within the isolate itself,
      > removing one more level of indirection.
      >
      > Bug: v8:6666
      > Change-Id: I4c612ad3d4112ec03c3b389f5bfb9cdc3dc8a671
      > Reviewed-on: https://chromium-review.googlesource.com/970468
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52073}
      
      TBR=mstarzinger@chromium.org
      
      Bug: v8:6666, v8:7580
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: I30639fe17ea345119d38a176a29d521c4b1904cb
      Reviewed-on: https://chromium-review.googlesource.com/975241
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52141}
      0031724f
  8. 21 Mar, 2018 2 commits
    • Jakob Gruber's avatar
      Revert "Reland "[builtins] Load external references from the external-reference-table"" · 8aa3a373
      Jakob Gruber authored
      This reverts commit f8184738.
      
      Reason for revert: arm is still unhappy https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20GC%20Stress/builds/6633
      
      Original change's description:
      > Reland "[builtins] Load external references from the external-reference-table"
      > 
      > This is a reland of 9afde91b
      > 
      > Original change's description:
      > > [builtins] Load external references from the external-reference-table
      > >
      > > Off-heap code cannot embed external references. With this CL, we load
      > > from the external reference table (reached through the root pointer)
      > > instead.
      > >
      > > In a follow-up, the table could be stored within the isolate itself,
      > > removing one more level of indirection.
      > >
      > > Bug: v8:6666
      > > Change-Id: I4c612ad3d4112ec03c3b389f5bfb9cdc3dc8a671
      > > Reviewed-on: https://chromium-review.googlesource.com/970468
      > > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#52073}
      > 
      > TBR=mstarzinger@chromium.org
      > 
      > Bug: v8:6666, v8:7580
      > Change-Id: I163cfc15605c1183b79ead77df0e37d71d60b6f7
      > Reviewed-on: https://chromium-review.googlesource.com/972821
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52118}
      
      TBR=yangguo@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org
      
      Change-Id: I5bcd1a1c84c6e9a6a24364390c9359d43c77120d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6666, v8:7580
      Reviewed-on: https://chromium-review.googlesource.com/973782Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52121}
      8aa3a373
    • jgruber's avatar
      Reland "[builtins] Load external references from the external-reference-table" · f8184738
      jgruber authored
      This is a reland of 9afde91b
      
      Original change's description:
      > [builtins] Load external references from the external-reference-table
      >
      > Off-heap code cannot embed external references. With this CL, we load
      > from the external reference table (reached through the root pointer)
      > instead.
      >
      > In a follow-up, the table could be stored within the isolate itself,
      > removing one more level of indirection.
      >
      > Bug: v8:6666
      > Change-Id: I4c612ad3d4112ec03c3b389f5bfb9cdc3dc8a671
      > Reviewed-on: https://chromium-review.googlesource.com/970468
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52073}
      
      TBR=mstarzinger@chromium.org
      
      Bug: v8:6666, v8:7580
      Change-Id: I163cfc15605c1183b79ead77df0e37d71d60b6f7
      Reviewed-on: https://chromium-review.googlesource.com/972821
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52118}
      f8184738
  9. 20 Mar, 2018 2 commits
  10. 01 Mar, 2018 1 commit
  11. 21 Feb, 2018 1 commit
    • jgruber's avatar
      [builtins] Add builtins constants list to roots · ad74be52
      jgruber authored
      This is a step towards off-heap (and eventually isolate-independent)
      builtins.
      
      Off-heap code cannot use the standard CallStub/CallRuntime mechanisms,
      since they directly embed the callee code object pointer within the
      caller.  There are two main issues with that: 1. the callee may be
      moved by GC, and 2. the pc-relative addressing we currently use breaks
      (i.e. ends up pointing to a random spot on the heap) when moving the
      caller off-heap.
      
      This CL addresses that by introducing a constants list stored on the
      roots array.  Instead of embedding code targets, we now have the option
      of loading them from constants list. The code sequence is:
      
      REX.W movq rax,[r13+0x4a0]  // Load the constants cache.
      REX.W movq rdx,[rax+0xf]    // From there, load the code target.
      ...
      REX.W addq rdx,0x5f         // Add instruction_start.
      call rdx
      
      There's no visible performance impact on the web tooling benchmark.
      
      This list will later be extended to also contain other constants such
      as Strings.
      
      Bug: v8:6666
      Change-Id: Ifcf67d1f682804ba0b6d3d0383216e16575b6bf5
      Reviewed-on: https://chromium-review.googlesource.com/923729
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51434}
      ad74be52