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. 24 May, 2019 1 commit
  3. 23 May, 2019 1 commit
  4. 22 May, 2019 1 commit
  5. 12 Mar, 2019 1 commit
  6. 11 Mar, 2019 1 commit
  7. 25 Feb, 2019 1 commit
  8. 23 Jan, 2019 1 commit
    • Jakob Gruber's avatar
      [arm] Add missing RELATIVE_CODE_TARGET iteration · b766299d
      Jakob Gruber authored
      Code object iteration was missing logic for RELATIVE_CODE_TARGET
      reloc entries. Garbage collection could thus miss objects that were
      referenced only as targets of pc-relative calls or jumps.
      
      RELATIVE_CODE_TARGETs are only used on arm, mips, and s390 and only
      at mksnapshot-time.
      
      This exposed another issue in that the interpreter entry trampoline
      copy we generate for profiling *did* contain relative calls in
      runtime-accessible code. This is a problem, since code space on arm is,
      by default, too large to be fully addressable through pc-relative
      calls. This CL thus also disables the related
      FLAG_interpreted_frames_native_stack feature on arm.
      
      Drive-by: Ensure the builtins constants table does not contain Code
      objects.
      
      Bug: v8:8713,v8:6666
      Change-Id: Idd914b46970ad08f9091fc72113fa7aed2732e71
      Reviewed-on: https://chromium-review.googlesource.com/c/1424866Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59023}
      b766299d
  9. 26 Dec, 2018 1 commit
  10. 18 Dec, 2018 1 commit
  11. 11 Dec, 2018 1 commit
  12. 26 Nov, 2018 1 commit
    • Marja Hölttä's avatar
      [iwyu] Include heap-inl.h less. · 0453d418
      Marja Hölttä authored
      - Remove heap-inl.h includes from places where it looked unnecessary. (This is a
        non-scientific approach, because it's probably pulled in indirectly anyway.)
      
      - Annotate places which include heap-inl.h because they need heap/ internals.
      
      - ACCESSORS legitimately needs heap-inl.h because of Heap::FromWritableHeapObject.
      
      - Add includes to heap/heap-write-barrier(-inl).h
      
      - A bunch of IWYU fixes discovered when working on this CL (includes which were
        missing because heap-inl.h pulls them in indirectly).
      
      BUG=v8:7490,v8:8238,v8:8499
      
      Change-Id: I00f9a74d430f13d7c080dca77a92b03bcca7ef96
      Reviewed-on: https://chromium-review.googlesource.com/c/1349241Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57814}
      0453d418
  13. 15 Nov, 2018 3 commits
    • Jakob Gruber's avatar
      Reland "[builtins] Support embedded builtins in nosnapshot builds" · e1044d10
      Jakob Gruber authored
      This is a reland of bf2f0a02
      
      Original change's description:
      > [builtins] Support embedded builtins in nosnapshot builds
      >
      > This CL adds support for embedded builtins in nosnap builds by creating
      > and setting an 'embedded blob' after builtin generation. Unlike
      > snapshot builds, the blob is not embedded into the .text section but
      > located on the C++ heap.
      >
      > This makes nosnap builds more consistent with mksnapshot, and allows us
      > to simplify there and in serializer cctests.
      >
      > Complications arise from the different workflows we need to support:
      >
      > 1. the standard mksnapshot build process,
      > 2. nosnap builds (which reuse the blob created by the first Isolate),
      > 2. and tests with various complicated serialization workflows.
      >
      > To cover all of these cases, this CL introduces two knobs to twiddle:
      >
      > 1. A 'sticky' embedded blob which overrides compiled-in default
      >    embedded blobs at Isolate setup.
      > 2. The blob lifecycle can be managed manually or through refcounting.
      >
      > These are described in more detail in isolate.cc.
      >
      > Tbr: ulan@chromium.org
      > Bug: v8:6666, v8:8350
      > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d
      > Reviewed-on: https://chromium-review.googlesource.com/c/1310195
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57523}
      
      Tbr: ulan@chromium.org,yangguo@chromium.org
      Bug: v8:6666, v8:8350
      Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738
      Reviewed-on: https://chromium-review.googlesource.com/c/1337578
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57540}
      e1044d10
    • Jakob Gruber's avatar
      Revert "[builtins] Support embedded builtins in nosnapshot builds" · 856be9c2
      Jakob Gruber authored
      This reverts commit bf2f0a02.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21753
      
      Original change's description:
      > [builtins] Support embedded builtins in nosnapshot builds
      > 
      > This CL adds support for embedded builtins in nosnap builds by creating
      > and setting an 'embedded blob' after builtin generation. Unlike
      > snapshot builds, the blob is not embedded into the .text section but
      > located on the C++ heap.
      > 
      > This makes nosnap builds more consistent with mksnapshot, and allows us
      > to simplify there and in serializer cctests.
      > 
      > Complications arise from the different workflows we need to support:
      > 
      > 1. the standard mksnapshot build process,
      > 2. nosnap builds (which reuse the blob created by the first Isolate),
      > 2. and tests with various complicated serialization workflows.
      > 
      > To cover all of these cases, this CL introduces two knobs to twiddle:
      > 
      > 1. A 'sticky' embedded blob which overrides compiled-in default
      >    embedded blobs at Isolate setup.
      > 2. The blob lifecycle can be managed manually or through refcounting.
      > 
      > These are described in more detail in isolate.cc.
      > 
      > Tbr: ulan@chromium.org
      > Bug: v8:6666, v8:8350
      > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d
      > Reviewed-on: https://chromium-review.googlesource.com/c/1310195
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57523}
      
      TBR=ulan@chromium.org,yangguo@chromium.org,jgruber@chromium.org
      
      Change-Id: I6e35a0cb7186fb50f1012f5c618fb8b48b24a813
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6666, v8:8350
      Reviewed-on: https://chromium-review.googlesource.com/c/1337577Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57529}
      856be9c2
    • Jakob Gruber's avatar
      [builtins] Support embedded builtins in nosnapshot builds · bf2f0a02
      Jakob Gruber authored
      This CL adds support for embedded builtins in nosnap builds by creating
      and setting an 'embedded blob' after builtin generation. Unlike
      snapshot builds, the blob is not embedded into the .text section but
      located on the C++ heap.
      
      This makes nosnap builds more consistent with mksnapshot, and allows us
      to simplify there and in serializer cctests.
      
      Complications arise from the different workflows we need to support:
      
      1. the standard mksnapshot build process,
      2. nosnap builds (which reuse the blob created by the first Isolate),
      2. and tests with various complicated serialization workflows.
      
      To cover all of these cases, this CL introduces two knobs to twiddle:
      
      1. A 'sticky' embedded blob which overrides compiled-in default
         embedded blobs at Isolate setup.
      2. The blob lifecycle can be managed manually or through refcounting.
      
      These are described in more detail in isolate.cc.
      
      Tbr: ulan@chromium.org
      Bug: v8:6666, v8:8350
      Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d
      Reviewed-on: https://chromium-review.googlesource.com/c/1310195Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57523}
      bf2f0a02
  14. 11 Oct, 2018 1 commit
  15. 10 Oct, 2018 1 commit
  16. 20 Sep, 2018 1 commit
  17. 20 Aug, 2018 1 commit
  18. 03 Jul, 2018 1 commit
  19. 25 May, 2018 1 commit
    • jgruber's avatar
      [builtins,x64] pc-relative builtin-to-builtin calls · e5630ea9
      jgruber authored
      This addresses one of the major remaining slowdowns with embedded
      builtins on x64.
      
      When generating code for a call to a builtin callee from a builtin
      caller, we'd look up the Code target object from the builtins constant
      list, calculate the location of the first instruction, and jump to it.
      Note that for embedded builtin callees, the Code object is itself only
      a trampoline to the off-heap code and thus an additional indirection.
      An example of the call sequence in pseudo-asm:
      
      // Load from the constants list.
      mov reg, [kRootPointer, kBuiltinsConstantListOffset]
      mov reg, [reg, offset_of_the_code_constant]
      // Calculate first instruction and call it.
      add reg, Code::kHeaderOffset
      call reg
      // The trampoline forwards to the off-heap area.
      mov kOffHeapTrampolineRegister, <off-heap instruction_start>
      jmp kOffHeapTrampolineRegister
      
      This CL changes calls to embedded builtin targets to use pc-relative
      addressing. This reduces the above instruction sequence to:
      
      call <pc-relative offset to target instruction_start>
      
      Embedded-to-embedded calls jump directly to the embedded instruction
      stream, bypassing the trampoline. Heap-to-embedded calls (and all
      calls to heap-builtins) use pc-relative addressing targeting the
      on-heap Code object.
      
      Other relevant platforms (arm,arm64,mips,mips64) do not use pc-relative
      calls. For these, we'll need a different solution, e.g. a table of
      embedded builtin addresses reachable from the root pointer, similar to
      the external reference table.
      
      Bug: v8:6666
      Change-Id: Ic0317d454e2da37d74eaecebcdfcbc0d5f5041ad
      Reviewed-on: https://chromium-review.googlesource.com/1068732
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53349}
      e5630ea9
  20. 07 May, 2018 1 commit
    • jgruber's avatar
      [builtins] Convert CEntry/GetProperty/StringAdd stubs to builtins · d8131cd6
      jgruber authored
      Stubs and builtins are very similar. The main differences are that
      stubs can be parameterized and may be generated at runtime, whereas
      builtins are generated at mksnapshot-time and shipped with the snapshot
      (or embedded into the binary).
      
      My main motivation for these conversions is that we can generate
      faster calls and jumps to (embedded) builtins callees from (embedded)
      builtin callers. Instead of going through the builtins constants table
      indirection, we can simply do a pc-relative call/jump.
      
      This also unlocks other refactorings, e.g. removal of
      CallRuntimeDelayed.
      
      TBR=mlippautz@chromium.org
      
      Bug: v8:6666
      Change-Id: I4cd63477f19a330ec70bbf20e2af8a42fb05fabb
      Reviewed-on: https://chromium-review.googlesource.com/1044245Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53027}
      d8131cd6
  21. 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
  22. 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
  23. 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
  24. 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
  25. 20 Mar, 2018 2 commits
  26. 05 Mar, 2018 1 commit
  27. 01 Mar, 2018 1 commit
  28. 23 Feb, 2018 1 commit
  29. 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