1. 06 Apr, 2021 1 commit
    • Patrick Thier's avatar
      Reland "[sparkplug] OSR Ignition -> Sparkplug" · 064ca18c
      Patrick Thier authored
      This is a reland of b9c521d0.
      
      Fixes crashes by calling kInstallBaselineCode from BaselineEntry if
      needed, i.e. when there is no feedback vector (required a bit of
      register rejiggling).
      This can happen with cross-realm calls. The OSR arming is stored as
      part of the BytecodeArray and therefore shared across realms.
      
      Original change's description:
      > [sparkplug] OSR Ignition -> Sparkplug
      >
      > Add support for OSR to baseline code.
      > We compile baseline and perform OSR immediately when the bytecode budget
      > interrupt hits.
      >
      > Drive-by: Clean-up deoptimizer special handling of JumpLoop by using
      > the newly introduced GetBaselinePCForNextExecutedBytecode instead of
      > GetBaselineEndPCForBytecodeOffset.
      >
      > Bug: v8:11420
      > Change-Id: Ifbea264d4a83a127dd2a11e28626bf2a5e8aca59
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784687
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73677}
      
      Bug: v8:11420
      Change-Id: I67325450514ed5a1170b730b1dd59fa6acc6e1d8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2800112Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73803}
      064ca18c
  2. 25 Mar, 2021 2 commits
  3. 18 Jan, 2021 1 commit
  4. 19 May, 2020 1 commit
  5. 20 Nov, 2019 1 commit
  6. 12 Nov, 2019 2 commits
  7. 24 May, 2019 1 commit
  8. 23 May, 2019 2 commits
  9. 21 May, 2019 1 commit
  10. 12 Dec, 2018 1 commit
  11. 07 Dec, 2018 3 commits
  12. 05 Dec, 2018 1 commit
  13. 22 Nov, 2018 1 commit
  14. 19 Nov, 2018 1 commit
    • Jakob Gruber's avatar
      [nojit] Move several IC stubs to builtins · 33da7197
      Jakob Gruber authored
      KeyedLoadSloppyArguments -> KeyedLoadIC_SloppyArguments
      KeyedStoreSloppyArguments -> KeyedStoreIC_SloppyArguments
      LoadIndexedIntercepter -> LoadIndexedInterceptorIC
      StoreInArrayLiteralSlowStub -> StoreInArrayLiteralIC_Slow
      StoreInterceptor -> StoreInterceptorIC
      StoreSlowElementStub -> KeyedStoreIC_Slow
      
      A few Store stubs were parameterized for the sole purpose of
      determining the KeyedAccessStoreMode later on. These are now
      implemented as a dedicated builtin for each store mode.
      
      Bug: v8:7777
      Change-Id: I743474b0e6c5d6ec2513bb9f8f3a93c5c0535927
      Reviewed-on: https://chromium-review.googlesource.com/c/1339859Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57592}
      33da7197
  15. 13 Sep, 2018 1 commit
  16. 17 Aug, 2018 1 commit
  17. 22 Jun, 2018 1 commit
  18. 29 May, 2018 2 commits
  19. 25 May, 2018 2 commits
  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. 14 Dec, 2017 1 commit
  22. 13 Dec, 2017 1 commit
  23. 20 Nov, 2017 1 commit
  24. 06 Nov, 2017 1 commit
  25. 25 Oct, 2017 1 commit
  26. 24 Oct, 2017 1 commit
    • Daniel Clifford's avatar
      Reimplement Array.prototype.slice in CSA and C++ · 6452b26a
      Daniel Clifford authored
      Previously, V8's slice was implemented in a combination of C++ and a 
      Javascript fallback. The disadvantage of this approach was that the
      fast-path required a call through the CEntryStub, which introduced
      considerable overhead for small arrays with fast elements kinds.
      
      Now the implementation primarily uses the CSA to generate both the
      full spec-complaint implementation as well as fast paths for argument
      objects and arrays with fast elements kinds. The CSA implementation
      uses a C++ implementation fallback in select situations where the the
      complexity of a CSA implementation would be too great and the
      CEntryStub overhead is not decisive (e.g. slices of dictionary
      elements arrays).
      
      Performance results on semi-random arrays with small number of
      elements (old vs. new):
      
      smi copy: 48.7 ms vs. 12 ms
      smi slice: 43.5 ms 14.8 ms
      object copy: 35.5 ms 7.7 ms
      object slice: 38.7 ms 8.8 ms
      dictionary slice: 2398.3 ms vs. 5.4 ms
      fast sloppy arguments slice: 9.6 ms vs. 7.2 ms
      slow sloppy arguments slice: 28.9 ms vs. 8.5 ms
      
      As a bonus, the new implementation is fully spec-compliant and fixes
      at least one existing bug.
      
      The design document for Array.prototype builtin rework can be found
      at https://goo.gl/wFHe2n
      
      Bug: v8:1956,v8:6601,v8:6710,v8:6978
      Change-Id: Ia0155bedcf39b4577605ff754f416c2af938efb7
      Reviewed-on: https://chromium-review.googlesource.com/574710
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48853}
      6452b26a
  27. 20 Oct, 2017 1 commit
  28. 18 Oct, 2017 1 commit
  29. 29 Sep, 2017 1 commit
  30. 25 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Properly optimize literals in inlined functions. · 855b88ae
      Benedikt Meurer authored
      When inlining based on SharedFunctionInfo rather than based on concrete
      JSFunction, we weren't able to properly optimize array, object and
      regexp literals inside the inlinee, because we didn't know the concrete
      FeedbackVector for the inlinee inside JSCreateLowering. This was because
      JSCreateLowering wasn't properly updated after the literals moved to the
      FeedbackVector. Now with this CL we also have the VectorSlotPair on the
      literal creation operators, just like we do for property accesses and
      calls, and are thus able to always access the appropriate FeedbackVector
      and optimize the literal creation.
      
      The impact is illustrated by the micro-benchmark on the tracking bug,
      which goes from
      
        createEmptyArrayLiteral: 1846 ms.
        createShallowArrayLiteral: 1868 ms.
        createShallowObjectLiteral: 2246 ms.
      
      to
      
        createEmptyArrayLiteral: 1175 ms.
        createShallowArrayLiteral: 1187 ms.
        createShallowObjectLiteral: 1195 ms.
      
      with this CL, so up to 2x faster now.
      
      Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin
      and cleanup the names of the other builtins to be consistent with the
      names of the TurboFan operators and Ignition bytecodes.
      
      Bug: v8:6856
      Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097
      Reviewed-on: https://chromium-review.googlesource.com/680656
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48140}
      855b88ae
  31. 05 Sep, 2017 2 commits
  32. 25 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      [Interpreter] Adapt Call bytecode handlers to drop their stack-frame. · 51a15140
      Ross McIlroy authored
      This change adapts the Call bytecode handlers such that they don't require
      a stack frame. It does this by modifying the call bytecode handler to
      tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the
      callee function will return to the InterpreterEntryTrampoline when it returns
      (since this is the return address on the interpreter frame), which is
      adapted to dispatch to the next bytecode handler. The return bytecode
      handler is modified to tail-call a new InterpreterExitTramoline instead
      of returning to the InterpreterEntryTrampoline.
      
      Overall this significanlty reduces the amount of stack space required for
      interpreter frames, increasing the maximum depth of recursive calls from
      around 6000 to around 12,500 on x64.
      
      BUG=chromium:753705
      
      Change-Id: I23328e4cef878df3aca4db763b47d72a2cce664c
      Reviewed-on: https://chromium-review.googlesource.com/634364
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47617}
      51a15140