1. 05 Nov, 2018 1 commit
  2. 19 Oct, 2018 1 commit
  3. 22 Aug, 2018 1 commit
  4. 21 Aug, 2018 1 commit
    • jgruber's avatar
      [builtins] Mark initial builtins on ia32 isolate-independent · 6ab19087
      jgruber authored
      This populates the isolate-independent builtin whitelist with initial
      builtins that do not access any isolate-dependent data and thus don't
      need the root register at all.
      
      Unlike most other platforms, we can't use a scratch register in the
      off-heap trampoline since there's no free register available. The
      trampolines on ia32 are thus implemented as pc-relative jumps
      (thankfully we can address the entire address space).
      
      Drive-by: Made Code::IsIsolateIndependent consistent with
      FinalizeEmbeddedCodeTargets. Code targets are only allowed on some
      platforms.
      
      Bug: v8:6666
      Change-Id: I0bf02eecba8a099afa7b7c892188cd377cbda840
      Reviewed-on: https://chromium-review.googlesource.com/1183224Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55265}
      6ab19087
  5. 17 Aug, 2018 3 commits
  6. 17 Jul, 2018 1 commit
  7. 09 Jul, 2018 1 commit
    • Sigurd Schneider's avatar
      [turbofan] Use relative calls/jumps on arm for builtins · 23dbb81d
      Sigurd Schneider authored
      This CL uses pc-relative jumps and calls (B/BL) for calls from embedded
      builtins to embedded builtins. To make this work, the code range size is
      limited to 32MB on arm during mksnapshot, which ensures that all builtin
      to builtin offsets for jumps/calls fit into the B/BL immediate. At code
      generation time, we put a placeholder into the instruction offset which
      we resolve to the right code object when the code is copied to the heap.
      We use a new relocation mode RELATIVE_CODE_TARGET for these relative jumps.
      The relocation mode RELATIVE_CODE_TARGET should never appear after
      generating the snapshot.
      
      We modify the target_address/set_target_address methods of RelocInfo
      such that they return the absolute target addresses for pc-relative B/BL
      instructions. This ensures that the GC can treat RELATIVE_CODE_TARGET in
      the same way as code targets. This, however, only matters during
      snapshot creation time, and production code never contains
      RELATIVE_CODE_TARGET relocations.
      
      Bug: v8:6666
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: If7eab83ad588859ca87c654a5ddc3e37caea884c
      Reviewed-on: https://chromium-review.googlesource.com/1117181Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54320}
      23dbb81d
  8. 06 Jul, 2018 1 commit
  9. 05 Jul, 2018 1 commit
  10. 03 Jul, 2018 1 commit
  11. 25 Jun, 2018 1 commit
  12. 22 Jun, 2018 1 commit
  13. 21 Jun, 2018 1 commit
  14. 20 Jun, 2018 2 commits
    • Ben L. Titzer's avatar
      [asm] Rework Assembler::IsolateData into Assembler::Options · 4252d53f
      Ben L. Titzer authored
      This CL attempts to simplify the Assembler's dependency on the
      isolate, in particular on a global "serializer_enabled" mode contained
      therein. The "serializer_enabled" condition enabled and disabled
      a number of things in both the assemblers and macro assemblers. To
      make these dependencies explicit, the Assembler::IsolateData is refactored
      to be a proper Assembler::Options struct that controls specific assembler
      behaviors, with default settings easily computable from the isolate.
      
      This also helps make the contract for compiling WASM code more explicit
      (since WASM code needs to have reloc info recorded for external references)
      we can explicitly enable this recording without trying to "trick" the
      assembler using "serializer_enabled".
      
      R=jgruber@chromium.org
      CC=mstarzinger@chromium.org, herhut@chromium.org
      
      Change-Id: I7a8ba49df7b75b292d73ec2aa6e507c27a3d99c8
      Reviewed-on: https://chromium-review.googlesource.com/1105982
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53890}
      4252d53f
    • Georgia Kouveli's avatar
      [arm64] Remove deopt tables. · cdb2ef01
      Georgia Kouveli authored
      We can instead pass the deopt id in a register, where before we were passing the
      deopt entry address. This removes the need for the deopt tables altogether,
      saving 192kB.
      
      Change-Id: I479d4de1a0245de328720b6b03a1955c8c63f696
      Reviewed-on: https://chromium-review.googlesource.com/1076472Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Cr-Commit-Position: refs/heads/master@{#53863}
      cdb2ef01
  15. 19 Jun, 2018 1 commit
  16. 18 Jun, 2018 1 commit
  17. 14 Jun, 2018 3 commits
    • Clemens Hammacher's avatar
      Reland "Introduce StdoutStream which prints to Android log or stdout" · 8e2e1257
      Clemens Hammacher authored
      This is a reland of 0909dbe3.
      Added missing V8_EXPORT_PRIVATE to AndroidLogStream.
      
      TBR=mstarzinger@chromium.org
      
      Original change's description:
      > Introduce StdoutStream which prints to Android log or stdout
      >
      > The often used construct {OFStream(stdout)} does not work on Android.
      > This CL introduces an {StdoutStream} which behaves exactly like
      > {OFStream(stdout)} on non-android platforms, and redirects to the
      > Android log on appropriate systems and configurations.
      >
      > R=mstarzinger@chromium.org
      >
      > Bug: v8:7820
      > Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
      > Reviewed-on: https://chromium-review.googlesource.com/1088911
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53692}
      
      Bug: v8:7820
      Change-Id: I8164bad78a401dbe4246c9ffcacd050fe511ed58
      Reviewed-on: https://chromium-review.googlesource.com/1100636Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53733}
      8e2e1257
    • Clemens Hammacher's avatar
      [wasm] Introduce JumpTableAssembler · 2dda64aa
      Clemens Hammacher authored
      Extract code generation (for the trampoline) from {wasm-code-manager.cc}
      to a new {JumpTableAssembler}. This prepares a CL to add more logic to
      the {JumpTableAssembler} to also generate jump tables for lazy
      compilation and tier up.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I383585b7e4b5a4af3ca08d07e374b44654c1a09f
      Reviewed-on: https://chromium-review.googlesource.com/1046585
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53729}
      2dda64aa
    • Michael Achenbach's avatar
      Revert "Introduce StdoutStream which prints to Android log or stdout" · d2e1620c
      Michael Achenbach authored
      This reverts commit 0909dbe3.
      
      Reason for revert: Blocks roll:
      https://chromium-review.googlesource.com/c/chromium/src/+/1099143
      
      Original change's description:
      > Introduce StdoutStream which prints to Android log or stdout
      > 
      > The often used construct {OFStream(stdout)} does not work on Android.
      > This CL introduces an {StdoutStream} which behaves exactly like
      > {OFStream(stdout)} on non-android platforms, and redirects to the
      > Android log on appropriate systems and configurations.
      > 
      > R=​mstarzinger@chromium.org
      > 
      > Bug: v8:7820
      > Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
      > Reviewed-on: https://chromium-review.googlesource.com/1088911
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53692}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org,jgruber@chromium.org,clemensh@chromium.org,bmeurer@chromium.org
      
      Change-Id: Iadadd9a0df10dca0fad647138a83db50148e864d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7820
      Reviewed-on: https://chromium-review.googlesource.com/1100635Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53725}
      d2e1620c
  18. 13 Jun, 2018 3 commits
  19. 07 Jun, 2018 2 commits
  20. 04 Jun, 2018 1 commit
    • Michael Starzinger's avatar
      [wasm] Make stack check independent of the Isolate. · c96ac82c
      Michael Starzinger authored
      This makes stack checks in WasmCode independent of the underlying
      Isolate by loading the limit address from the WasmInstanceObject instead
      of embedding it into the instruction stream. It hence removes the last
      use of the Isolate field from WasmGraphBuilder.
      
      Additionally this introduces the notion of a "runtime stub" which
      represents stub code global to the NativeModule that can be directly
      called from each WasmCode in the same module. These stubs can act as
      trampolines via which Isolate-independent WasmCode can enter other V8
      builtins or runtime functions that remain Isolate-dependent. They will
      eventually replace the current "trampoline" in a NativeModule.
      
      R=titzer@chromium.org
      BUG=v8:7424
      
      Change-Id: Ie1f5582ee656b1ab7716ea06316d6e21a0268e74
      Reviewed-on: https://chromium-review.googlesource.com/1078732
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53487}
      c96ac82c
  21. 28 May, 2018 1 commit
  22. 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
  23. 15 May, 2018 1 commit
  24. 30 Apr, 2018 1 commit
  25. 18 Apr, 2018 1 commit
    • Stephan Herhut's avatar
      Reland "Introduce CodeReference" · 9a200cd2
      Stephan Herhut authored
      This is a reland of 4d7ad46d
      
      Original change's description:
      > Introduce CodeReference
      >
      > Add a struct CodeReference that can be stack allocated to pass a
      > reference to either an on-heap code object or off-heap WasmCode object
      > in a gc safe manner. The struct also provides a common interface such
      > that code can be written independently of the kind of code object it
      > references.
      >
      > Change-Id: I5a6f74462e6e141d167c7fd9bac8c21941fd83b1
      > Reviewed-on: https://chromium-review.googlesource.com/977905
      > Commit-Queue: Stephan Herhut <herhut@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52580}
      
      Change-Id: I40861474fe4a3efd72e6c59e2e7b847ab6772735
      Reviewed-on: https://chromium-review.googlesource.com/1013939
      Commit-Queue: Stephan Herhut <herhut@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52665}
      9a200cd2
  26. 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
  27. 12 Apr, 2018 2 commits
  28. 09 Apr, 2018 1 commit
  29. 06 Apr, 2018 1 commit
  30. 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
  31. 04 Apr, 2018 1 commit
    • Ben Titzer's avatar
      Revert "[wasm] Merge the WasmContext into WasmInstanceObject" · 8adb94fc
      Ben Titzer authored
      This reverts commit 57bf0bfe.
      
      Reason for revert: <INSERT REASONING HERE>
      
      Original change's description:
      > [wasm] Merge the WasmContext into WasmInstanceObject
      > 
      > This change makes lifetime management of WasmCode much simpler.
      > By using the WasmInstanceObject as the context for WASM code execution,
      > including the pointer to the memory base and indirect function tables,
      > this keeps the instance alive when WASM code is on the stack, since
      > the instance object is passed as a parameter and spilled onto the stack.
      > This is in preparation of sharing the code between instances and
      > isolates.
      > 
      > Bug: v8:7424
      > 
      > Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
      > Reviewed-on: https://chromium-review.googlesource.com/958520
      > Commit-Queue: Ben Titzer <titzer@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52361}
      
      TBR=mstarzinger@chromium.org,titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org
      
      Change-Id: I653e27b46dbc43ad773eda4292d521a508f42d79
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7424
      Reviewed-on: https://chromium-review.googlesource.com/995418Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52364}
      8adb94fc