1. 09 Nov, 2017 1 commit
    • Karl Schimpf's avatar
      Add capability to handle CSP 'wasm-eval' in V8 · 1719ecb9
      Karl Schimpf authored
      Like CSP flag 'unsafe-eval', which communicates if both JS source
      files and WASM binary files may be compiled, this CL adds a similar
      flag for the compilation of WASM binary files.
      
      That is, a WASM binary file will be compiled only if the new flag is
      defined, or the flag for 'unsafe-eval' allows it. These flags are
      implemented as callback functions on the isolate. The callbacks get a
      (CSP) context, and a string, and returns the corresponding value of
      the flag.
      
      Both callbacks are initialized with the nullptr, and is used to
      communicate that no CSP policy is defined. This allows this concept to
      work, independent of it running in Chrome.
      
      It also does a small clean up in api.cc to use macro CALLER_SETTERS,
      instead of explicit code when appropriate.
      
      Bug: v8:7041
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Idb3356574ae2a298057e6b7bccbd3492831952ae
      Reviewed-on: https://chromium-review.googlesource.com/759162Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
      Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49243}
      1719ecb9
  2. 07 Nov, 2017 1 commit
  3. 31 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [ic] Add OOB support to KeyedLoadIC. · 6dc35ab4
      Benedikt Meurer authored
      This adds support to the KeyedLoadIC to ignore out of bounds accesses
      for Strings and return undefined instead. We add a dedicated bit to the
      Smi handler to encode the OOB state and have TurboFan generate appropriate
      code for that case as well. This is mostly useful when programs
      accidentially access past the length of a string, which was observed and
      fixed for example in Babel recently, see
      
        https://github.com/babel/babel/pull/6589
      
      for details. The idea is to also extend this mechanism to Arrays and
      maybe other receivers, as reading beyond the length is also often used
      in jQuery and other popular libraries.
      
      Note that this is considered a mitigation for a performance cliff and
      not a general optimization of OOB accesses. These should still be
      avoided and handled properly instead.
      
      This seems to further improve the babel test on the web-tooling-benchmark
      by around 1%, because the OOB access no longer turns the otherwise
      MONOMORPHIC access into MEGAMORPHIC state.
      
      Bug: v8:6936, v8:7014
      Change-Id: I9df03304e056d7001a65da8e9621119f8e9bb55b
      Reviewed-on: https://chromium-review.googlesource.com/744022
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49049}
      6dc35ab4
  4. 13 Oct, 2017 1 commit
  5. 22 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Introduce dedicated GetTemplateObject bytecode. · 79ac69b8
      Benedikt Meurer authored
      Tagged templates were previously desugared during parsing using some
      combination of runtime support written in JavaScript and C++, which
      prevented some optimizations from happening, namely the constant folding
      of the template object in TurboFan optimized code. This CL adds a new
      bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
      node), which represents the abstract operation in the ES6 specification
      and allows TurboFan to simply constant-fold template objects at compile
      time (which is explicitly supported by the specification).
      
      This also pays down some technical debt by removing the template.js
      runtime support and therefore should reduce the size of the native
      context (snapshot) a bit.
      
      With this change in-place the ES6 version microbenchmark in the
      referenced tracking bug is now faster than the transpiled Babel
      code, it goes from
      
        templateStringTagES5: 4552 ms.
        templateStringTagES6: 14185 ms.
        templateStringTagBabel: 7626 ms.
      
      to
      
        templateStringTagES5: 4515 ms.
        templateStringTagES6: 7491 ms.
        templateStringTagBabel: 7639 ms.
      
      which corresponds to a solid 45% reduction in execution time. With some
      further optimizations the ES6 version should be able to outperform the
      ES5 version. This micro-benchmark should be fairly representative of the
      six-speed-templatestringtag-es6 benchmark, and as such that benchmark
      should also improve by around 50%.
      
      Bug: v8:6819,v8:6820
      Tbr: mlippautz@chromium.org
      Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
      Reviewed-on: https://chromium-review.googlesource.com/677462Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarCaitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48126}
      79ac69b8
  6. 20 Sep, 2017 1 commit
  7. 05 Sep, 2017 1 commit
    • Juliana Franco's avatar
      Remove weak-list of optimized JS functions. · f0acede9
      Juliana Franco authored
      This CL removes the weak-list of JS functions from the context
      and all the code that iterares over it. This list was being used
      mainly during deoptimization (for code unlinking) and during
      garbage collection. Removing it will improve performance of
      programs that create many closures and trigger many scavenge GC
      cycles.
      
      No extra work is required during garbage collection. However,
      given that we no longer unlink code from JS functions during
      deoptimization, we leave it as it is, and on its next activation
      we check whether the mark_for_deoptimization bit of that code is
      set, and if it is, than we unlink it and jump to lazy compiled
      code. This check happens in the prologue of every code object.
       
      We needed to change/remove the cctests that used to check
      something on this list.
       
      Working in x64, ia32, arm64, arm, mips64 and mips. 
       
      
      Bug: v8:6637
      Change-Id: Ica99a12fd0351ae985e9a287918bf28caf6d2e24
      TBR: mstarzinger@chromium.org
      Reviewed-on: https://chromium-review.googlesource.com/647596
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47808}
      f0acede9
  8. 04 Sep, 2017 2 commits
    • Michael Achenbach's avatar
      Revert "Remove weak-list of optimized JS functions." · 36b50283
      Michael Achenbach authored
      This reverts commit 84c2dfce.
      
      Reason for revert:
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876
      
      Original change's description:
      > Remove weak-list of optimized JS functions.
      > 
      > This CL removes the weak-list of JS functions from the context
      > and all the code that iterares over it. This list was being used
      > mainly during deoptimization (for code unlinking) and during
      > garbage collection. Removing it will improve performance of
      > programs that create many closures and trigger many scavenge GC
      > cycles.
      > 
      > No extra work is required during garbage collection. However,
      > given that we no longer unlink code from JS functions during
      > deoptimization, we leave it as it is, and on its next activation
      > we check whether the mark_for_deoptimization bit of that code is
      > set, and if it is, than we unlink it and jump to lazy compiled
      > code. This check happens in the prologue of every code object.
      > 
      > We needed to change/remove the cctests that used to check
      > something on this list.
      > 
      > Working in x64, ia32, arm64, arm, mips64 and mips. 
      > 
      > Bug: v8:6637
      > Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
      > Reviewed-on: https://chromium-review.googlesource.com/600427
      > Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47790}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com
      
      Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6637
      Reviewed-on: https://chromium-review.googlesource.com/647540Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47792}
      36b50283
    • Juliana Franco's avatar
      Remove weak-list of optimized JS functions. · 84c2dfce
      Juliana Franco authored
      This CL removes the weak-list of JS functions from the context
      and all the code that iterares over it. This list was being used
      mainly during deoptimization (for code unlinking) and during
      garbage collection. Removing it will improve performance of
      programs that create many closures and trigger many scavenge GC
      cycles.
      
      No extra work is required during garbage collection. However,
      given that we no longer unlink code from JS functions during
      deoptimization, we leave it as it is, and on its next activation
      we check whether the mark_for_deoptimization bit of that code is
      set, and if it is, than we unlink it and jump to lazy compiled
      code. This check happens in the prologue of every code object.
      
      We needed to change/remove the cctests that used to check
      something on this list.
      
      Working in x64, ia32, arm64, arm, mips64 and mips. 
      
      Bug: v8:6637
      Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
      Reviewed-on: https://chromium-review.googlesource.com/600427
      Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47790}
      84c2dfce
  9. 21 Aug, 2017 1 commit
  10. 11 Aug, 2017 1 commit
  11. 09 Aug, 2017 1 commit
  12. 08 Aug, 2017 2 commits
  13. 01 Aug, 2017 1 commit
  14. 31 Jul, 2017 2 commits
  15. 24 Jul, 2017 2 commits
  16. 20 Jul, 2017 1 commit
  17. 19 Jul, 2017 1 commit
  18. 17 Jul, 2017 1 commit
  19. 13 Jul, 2017 1 commit
  20. 10 Jul, 2017 2 commits
    • Benedikt Meurer's avatar
      [builtins] Port Map and Set iterators to CodeStubAssembler. · 3b84cbfe
      Benedikt Meurer authored
      This is the next step towards faster Map and Set iteration. It
      introduces the appropriate instance types for Map and Set
      iterators (following the pattern for Array iterators) and migrates
      the following builtins to the CodeStubAssembler:
      
        - Set.prototype.entries
        - Set.prototype.values
        - Map.prototype.entries
        - Map.prototype.keys
        - Map.prototype.values
        - %SetIteratorPrototype%.next
        - %MapIteratorPrototype%.next
      
      This already provides a significant performance boost for regular
      for-of iteration of Sets and Maps, by a factor of 5-10 depending
      on the input. The final step will be to inline some fast-paths
      into TurboFan.
      
      Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
      intrinsics and runtime functions.
      
      TBR=jgruber@chromium.org
      
      Bug: v8:6344, v8:6571, chromium:740122
      Change-Id: I3ab0ee49e2afe8d4295707a5ecbd51adda621918
      Reviewed-on: https://chromium-review.googlesource.com/563626
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46497}
      3b84cbfe
    • Michael Achenbach's avatar
      Revert "[builtins] Port Map and Set iterators to CodeStubAssembler." · 5a6e24e9
      Michael Achenbach authored
      This reverts commit 3f22832b.
      
      Reason for revert: Layout tests:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16849
      
      Original change's description:
      > [builtins] Port Map and Set iterators to CodeStubAssembler.
      > 
      > This is the next step towards faster Map and Set iteration. It
      > introduces the appropriate instance types for Map and Set
      > iterators (following the pattern for Array iterators) and migrates
      > the following builtins to the CodeStubAssembler:
      > 
      >   - Set.prototype.entries
      >   - Set.prototype.values
      >   - Map.prototype.entries
      >   - Map.prototype.keys
      >   - Map.prototype.values
      >   - %SetIteratorPrototype%.next
      >   - %MapIteratorPrototype%.next
      > 
      > This already provides a significant performance boost for regular
      > for-of iteration of Sets and Maps, by a factor of 5-10 depending
      > on the input. The final step will be to inline some fast-paths
      > into TurboFan.
      > 
      > Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
      > intrinsics and runtime functions.
      > 
      > Bug: v8:6571, chromium:740122
      > Change-Id: Iad7a7dec643d8f8b5799327f89a351108ae856bf
      > Reviewed-on: https://chromium-review.googlesource.com/563399
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46492}
      
      TBR=jgruber@chromium.org,bmeurer@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:6571, chromium:740122
      Change-Id: Iadb48d72e3b85ec8ad880e50ab7912c5502caf07
      Reviewed-on: https://chromium-review.googlesource.com/564419Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46495}
      5a6e24e9
  21. 08 Jul, 2017 1 commit
    • Benedikt Meurer's avatar
      [builtins] Port Map and Set iterators to CodeStubAssembler. · 3f22832b
      Benedikt Meurer authored
      This is the next step towards faster Map and Set iteration. It
      introduces the appropriate instance types for Map and Set
      iterators (following the pattern for Array iterators) and migrates
      the following builtins to the CodeStubAssembler:
      
        - Set.prototype.entries
        - Set.prototype.values
        - Map.prototype.entries
        - Map.prototype.keys
        - Map.prototype.values
        - %SetIteratorPrototype%.next
        - %MapIteratorPrototype%.next
      
      This already provides a significant performance boost for regular
      for-of iteration of Sets and Maps, by a factor of 5-10 depending
      on the input. The final step will be to inline some fast-paths
      into TurboFan.
      
      Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
      intrinsics and runtime functions.
      
      Bug: v8:6571, chromium:740122
      Change-Id: Iad7a7dec643d8f8b5799327f89a351108ae856bf
      Reviewed-on: https://chromium-review.googlesource.com/563399
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46492}
      3f22832b
  22. 07 Jul, 2017 2 commits
  23. 05 Jul, 2017 1 commit
  24. 30 Jun, 2017 1 commit
    • Mathias Bynens's avatar
      [elements] Rename FAST elements kinds · 26c00f4a
      Mathias Bynens authored
      The `FAST_` prefix doesn’t make much sense — they’re all just different cases
      with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
      vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.
      
      This patch renames the FAST elements kinds as follows:
      
      - e.g. FAST_ELEMENTS => PACKED_ELEMENTS
      - e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS
      
      The following exceptions are left intact, for lack of a better name:
      
      - FAST_SLOPPY_ARGUMENTS_ELEMENTS
      - SLOW_SLOPPY_ARGUMENTS_ELEMENTS
      - FAST_STRING_WRAPPER_ELEMENTS
      - SLOW_STRING_WRAPPER_ELEMENTS
      
      This makes it easier to reason about elements kinds, and less confusing to
      explain how they’re used.
      
      R=jkummerow@chromium.org, cbruni@chromium.org
      BUG=v8:6548
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
      Reviewed-on: https://chromium-review.googlesource.com/556032Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46361}
      26c00f4a
  25. 29 Jun, 2017 1 commit
  26. 22 Jun, 2017 2 commits
  27. 19 Jun, 2017 1 commit
  28. 14 Jun, 2017 2 commits
  29. 13 Jun, 2017 1 commit
  30. 12 Jun, 2017 1 commit
  31. 15 May, 2017 2 commits
    • Clemens Hammacher's avatar
      Revert "[builtins] port Promise.all to CSA" · ae421616
      Clemens Hammacher authored
      This reverts commit 7ef1df85.
      
      Reason for revert: Breaks inspector/debugger/get-possible-breakpoints-restrict-to-function: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/13191/steps/Check/logs/get-possible-breakpoi..
      
      Original change's description:
      > [builtins] port Promise.all to CSA
      > 
      > Introduces CodeStubAssembler helpers for common Iterator operations
      > (GetIterator, IteratorStep, IteratorClose).
      > 
      > Moves the Promise.all resolveElement closure and it's caller to
      > builtins-promise-gen.cc.
      > 
      > Instead of creating an internal array (and copying its elements into a result
      > array), a single JSArray is allocated, and appended with BuildAppendJSArray(),
      > falling back to %CreateDataProperty(), and elements are updated in the resolve
      > closure the same way. This should always be unobservable.
      > 
      > This CL increases the size of snapshot_blob.bin on an x64.debug build by 11.44kb
      > 
      > BUG=v8:5343
      > R=​cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org
      > 
      > Change-Id: Id69b7f76866b29caccd97f35870154c4be85f418
      > Reviewed-on: https://chromium-review.googlesource.com/497974
      > Commit-Queue: Caitlin Potter <caitp@igalia.com>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45306}
      
      TBR=adamk@chromium.org,cbruni@chromium.org,gsathya@chromium.org,caitp@igalia.com,jgruber@chromium.org,ishell@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5343
      
      Change-Id: I831738003643561fa628266af2bcebbb18000e55
      Reviewed-on: https://chromium-review.googlesource.com/506014Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45313}
      ae421616
    • Caitlin Potter's avatar
      [builtins] port Promise.all to CSA · 7ef1df85
      Caitlin Potter authored
      Introduces CodeStubAssembler helpers for common Iterator operations
      (GetIterator, IteratorStep, IteratorClose).
      
      Moves the Promise.all resolveElement closure and it's caller to
      builtins-promise-gen.cc.
      
      Instead of creating an internal array (and copying its elements into a result
      array), a single JSArray is allocated, and appended with BuildAppendJSArray(),
      falling back to %CreateDataProperty(), and elements are updated in the resolve
      closure the same way. This should always be unobservable.
      
      This CL increases the size of snapshot_blob.bin on an x64.debug build by 11.44kb
      
      BUG=v8:5343
      R=cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org
      
      Change-Id: Id69b7f76866b29caccd97f35870154c4be85f418
      Reviewed-on: https://chromium-review.googlesource.com/497974
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45306}
      7ef1df85