1. 16 Nov, 2017 3 commits
  2. 15 Nov, 2017 5 commits
  3. 14 Nov, 2017 1 commit
  4. 13 Nov, 2017 2 commits
  5. 10 Nov, 2017 2 commits
  6. 09 Nov, 2017 2 commits
  7. 08 Nov, 2017 3 commits
    • Yang Guo's avatar
      [map] Fix map constructor to correctly throw. · 3c8195d9
      Yang Guo authored
      We need to throw before rethrowing, otherwise the exception does
      not trigger a debugger event and is not reported if uncaught.
      
      R=gsathya@chromium.org, jgruber@chromium.org
      
      Bug: v8:7047
      Change-Id: I7ce0253883a21d6059e4e0ed0fc56dc55a0dcba6
      Reviewed-on: https://chromium-review.googlesource.com/758372Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49237}
      3c8195d9
    • jgruber's avatar
      [factory] Simplify JSFunction creation · 72230246
      jgruber authored
      There's three common situations in which we need to create JSFunction
      objects.  1) from the compiler, 2) from tests, and 3) everything else
      (mostly during bootstrapping).
      
      This is an attempt to simplify case 3), which previously relied on
      several Factory::NewFunction overloads where it was not clear how the
      semantics of each overload differed.
      
      This CL removes all but one overload, and packs arguments into a new
      NewFunctionArgs helper class.
      
      It also removes the hacks around
      SFI::set_lazy_deserialization_builtin_id by explicitly passing
      builtin_id into Factory::NewSharedFunctionInfo.
      
      Drive-by-fix: Properly set is_constructor hint in
      SimpleCreateSharedFunctionInfo.
      
      Bug: v8:6624
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ica94d95e72e443055db5e7ff9e8cdf4115201ef1
      Reviewed-on: https://chromium-review.googlesource.com/757094
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49224}
      72230246
    • jgruber's avatar
      [string] Fix regexp fast path in MaybeCallFunctionAtSymbol · 55a98076
      jgruber authored
      The regexp fast path in MaybeCallFunctionAtSymbol had an issue in which
      we'd call ToString after checking that the given {object} was a fast
      regexp and deciding to take the fast path. This is invalid since
      ToString() can call into user-controlled JS and may mutate {object}.
      
      There's no way to place the ToString call correctly in this instance:
      1 before BranchIfFastRegExp, it's a spec violation if we end up on the
        slow regexp path;
      2 the problem with the current location is already described above;
      3 and we can't place it into the fast-path regexp builtin (e.g.
        RegExpReplace) either due to the same reasons as 1.
      
      The solution in this CL is to restrict the fast path to string
      arguments only, i.e. cases where ToString would be a nop and can safely
      be skipped.
      
      Bug: chromium:782145
      Change-Id: Ifd35b3a9a6cf2e77c96cb860a8ec98eaec35aa85
      Reviewed-on: https://chromium-review.googlesource.com/758257
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49213}
      55a98076
  8. 07 Nov, 2017 5 commits
  9. 06 Nov, 2017 3 commits
  10. 03 Nov, 2017 1 commit
  11. 02 Nov, 2017 3 commits
    • peterwmwong's avatar
      [builtins] Port WeakMap.p.delete and WeakSet.p.delete to CSA from JS · 43858375
      peterwmwong authored
      - Add WeakMapPrototypeDelete and WeakSetPrototypeDelete TFJ builtins
        - Fast paths when it's not necessary to shrink the table
      - Add WeakCollectionDelete TFS
      
      Some quick benchmarks shows 1.4x - 2.15x gains in performance.
      https://github.com/peterwmwong/v8-perf/blob/master/weakcollection-delete/README.md
      
      Bug: v8:5049, v8:6604
      Change-Id: I14036df153f3a0242f9083d751658b868b16660a
      Reviewed-on: https://chromium-review.googlesource.com/743864Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49076}
      43858375
    • Yang Guo's avatar
      Perform stack check on Proxy call trap. · 1e77461d
      Yang Guo authored
      Proxy's call trap can be used to cause recursion.
      
      R=bmeurer@chromium.org, tebbi@chromium.org
      
      Bug: chromium:779344
      Change-Id: I19c989f618f7230028ebe18c3415bc3f4bd72b93
      Reviewed-on: https://chromium-review.googlesource.com/743782Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49069}
      1e77461d
    • Benedikt Meurer's avatar
      [builtins] Support two byte strings in StringEqual builtin. · f597eec1
      Benedikt Meurer authored
      This CL adds support for two byte string comparisons to the StringEqual
      builtin, which so far was bailing out to the generic %StringEqual
      runtime function whenever any two-byte string was involved. This made
      comparisons that involved two-byte strings, either comparing them to
      one-byte strings or comparing two two-byte strings, up to 3x slower than
      if only one-byte strings were involved.
      
      With this change, all direct string (SeqString or ExternalString)
      equality checks are roughly on par now, and the weird performance cliff
      is gone. On the micro-benchmark from the bug we go from
      
        stringEqualBothOneByteSeqString: 162 ms.
        stringEqualTwoByteAndOneByteSeqString: 446 ms.
        stringEqualOneByteAndTwoByteSeqString: 438 ms.
        stringEqualBothTwoByteSeqString: 472 ms.
      
      to
      
        stringEqualBothOneByteSeqString: 151 ms.
        stringEqualTwoByteAndOneByteSeqString: 158 ms.
        stringEqualOneByteAndTwoByteSeqString: 166 ms.
        stringEqualBothTwoByteSeqString: 160 ms.
      
      which is the desired result. On the esprima test of the
      web-tooling-benchmark we seem to improve by 1-2%, which corresponds to
      the savings of going to the runtime for many StringEqual comparisons.
      
      Drive-by-cleanup: Introduce LoadAndUntagStringLength helper into the CSA
      with proper typing to avoid the unnecessary shifts on 64-bit platforms
      when keeping the length tagged initially in StringEqual.
      
      Bug: v8:4913, v8:6365, v8:6371, v8:6936, v8:7022
      Change-Id: I566f4b80e217513775ffbd35e0480154abf59b27
      Reviewed-on: https://chromium-review.googlesource.com/749223Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49067}
      f597eec1
  12. 01 Nov, 2017 1 commit
  13. 30 Oct, 2017 2 commits
  14. 28 Oct, 2017 1 commit
  15. 27 Oct, 2017 4 commits
  16. 26 Oct, 2017 2 commits