1. 02 Nov, 2017 10 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
    • Michael Achenbach's avatar
      Revert "Revert "[cctest] Clarify that tests for sync instructions are simulator specific"" · d9c5e5d0
      Michael Achenbach authored
      This reverts commit 1feadfe8.
      
      Reason for revert: Reland as bot stayed red after revert.
      
      Original change's description:
      > Revert "[cctest] Clarify that tests for sync instructions are simulator specific"
      > 
      > This reverts commit 4013518f.
      > 
      > Reason for revert:
      > https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress
      > 
      > Original change's description:
      > > [cctest] Clarify that tests for sync instructions are simulator specific
      > > 
      > > Some tests were recently added to test-simulator-arm.cc, however this file is
      > > meant for tests that are specific to the simulator and therefore are not written
      > > to work on hardware. While this sounds surprising, the reason is that our simulation
      > > of synchronisation instructions is more conservative than on hardware.
      > > 
      > > To make this more clear, this patch renames the "test-simulator-arm{,64}.cc"
      > > files to "test-sync-primitives-arm{,64}.cc", and moves the vneg and vabs tests
      > > into "test-assembler-arm.cc" which is were tests that are garanteed to work in
      > > either native or simulated environments live.
      > > 
      > > Finally, take the opportunity to share a little bit of code.
      > > 
      > > Bug: v8:6963
      > > Change-Id: Ifb85d3671c823b9bba73d09f419536b089a4e87c
      > > Reviewed-on: https://chromium-review.googlesource.com/749387
      > > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > > Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      > > Cr-Commit-Position: refs/heads/master@{#49073}
      > 
      > TBR=clemensh@chromium.org,pierre.langlois@arm.com,bmeurer@chromium.org
      > 
      > Change-Id: I1bfb4e9c7c18b716f417a84b18a14cb2e1fa3a7a
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: v8:6963
      > Reviewed-on: https://chromium-review.googlesource.com/750624
      > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49074}
      
      TBR=machenbach@chromium.org,clemensh@chromium.org,pierre.langlois@arm.com,bmeurer@chromium.org
      
      Change-Id: I5af7bd3678758130534730a2f6f0b651b64c6956
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6963
      Reviewed-on: https://chromium-review.googlesource.com/750903Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49075}
      d9c5e5d0
    • Michael Achenbach's avatar
      Revert "[cctest] Clarify that tests for sync instructions are simulator specific" · 1feadfe8
      Michael Achenbach authored
      This reverts commit 4013518f.
      
      Reason for revert:
      https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress
      
      Original change's description:
      > [cctest] Clarify that tests for sync instructions are simulator specific
      > 
      > Some tests were recently added to test-simulator-arm.cc, however this file is
      > meant for tests that are specific to the simulator and therefore are not written
      > to work on hardware. While this sounds surprising, the reason is that our simulation
      > of synchronisation instructions is more conservative than on hardware.
      > 
      > To make this more clear, this patch renames the "test-simulator-arm{,64}.cc"
      > files to "test-sync-primitives-arm{,64}.cc", and moves the vneg and vabs tests
      > into "test-assembler-arm.cc" which is were tests that are garanteed to work in
      > either native or simulated environments live.
      > 
      > Finally, take the opportunity to share a little bit of code.
      > 
      > Bug: v8:6963
      > Change-Id: Ifb85d3671c823b9bba73d09f419536b089a4e87c
      > Reviewed-on: https://chromium-review.googlesource.com/749387
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      > Cr-Commit-Position: refs/heads/master@{#49073}
      
      TBR=clemensh@chromium.org,pierre.langlois@arm.com,bmeurer@chromium.org
      
      Change-Id: I1bfb4e9c7c18b716f417a84b18a14cb2e1fa3a7a
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6963
      Reviewed-on: https://chromium-review.googlesource.com/750624Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49074}
      1feadfe8
    • Pierre Langlois's avatar
      [cctest] Clarify that tests for sync instructions are simulator specific · 4013518f
      Pierre Langlois authored
      Some tests were recently added to test-simulator-arm.cc, however this file is
      meant for tests that are specific to the simulator and therefore are not written
      to work on hardware. While this sounds surprising, the reason is that our simulation
      of synchronisation instructions is more conservative than on hardware.
      
      To make this more clear, this patch renames the "test-simulator-arm{,64}.cc"
      files to "test-sync-primitives-arm{,64}.cc", and moves the vneg and vabs tests
      into "test-assembler-arm.cc" which is were tests that are garanteed to work in
      either native or simulated environments live.
      
      Finally, take the opportunity to share a little bit of code.
      
      Bug: v8:6963
      Change-Id: Ifb85d3671c823b9bba73d09f419536b089a4e87c
      Reviewed-on: https://chromium-review.googlesource.com/749387Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Cr-Commit-Position: refs/heads/master@{#49073}
      4013518f
    • Benedikt Meurer's avatar
      [ic] Internalize strings on the fly in KeyedLoadICGeneric. · 6366a010
      Benedikt Meurer authored
      This turns on the existing --internalize_on_the_fly flag for the
      MEGAMORPHIC KeyedLoadIC to properly internalize strings before
      looking up the property. This avoids the otherwise taken runtime
      call to %KeyedGetProperty, which is definitely slower.
      
      Initially the --internalize_on_the_fly flag was turned off because
      internalizing strings on the fly causes too much traffic on the
      megamorphic stub cache. We avoid this problem here by not probing
      the stub cache in that case, which still gives the benefit of not
      having to go to the runtime.
      
      This improves the babylon test on the web-tooling-benchmark by around
      2-3% and will probably also help with several tests (like React or
      Ember) on the Speedometer benchmark.
      
      If this CL causes trouble (i.e. tanks something important), we can
      just turn off the --internalize_on_the_fly flag again.
      
      Bug: v8:6936, v8:7026
      Change-Id: Ia59a8a3799d9624d831d66b05bae3ecef31cee0a
      Reviewed-on: https://chromium-review.googlesource.com/750821Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49072}
      6366a010
    • Andreas Haas's avatar
      [wasm] Improve stack check in the interpreter · 793c52ed
      Andreas Haas authored
      The existing stack check only checked the number of stack frames on the
      stack, not the actual size of the stack frames. In the test case, each
      stack frame is huge, and the interpreter runs out of memory before the
      stack check stops the execution. With this change we take the size of
      the value stack and the size of the control stack and compare their sum
      to the stack limit of V8. Note that this stack limit is kind of
      arbitrary, because the stack space of the interpreter is not on the
      actual runtime stack but allocated in zone memory, and the stack check
      exists to simulate stack overflows in compiled code, not to prevent
      actual stack overflows.
      
      R=clemensh@chromium.org
      TEST=mjsunit/regress/wasm/regress-778917
      
      Bug: chromium:778917
      Change-Id: Ife47631fcb1a178a68facab1e42c0069b12c0155
      Reviewed-on: https://chromium-review.googlesource.com/744003
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49071}
      793c52ed
    • Benedikt Meurer's avatar
      Disable --string-slices. · fd5b067f
      Benedikt Meurer authored
      This is an experiment to quantify the impact of SlicedStrings on both
      performance and memory usage. The intention is to get Canary coverage
      for the experiment and then decide how to proceed.
      
      Bug: v8:7025
      Change-Id: Ied548cd9e2fab127c1ad2aea3e60b2615d3de663
      Reviewed-on: https://chromium-review.googlesource.com/750082
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49070}
      fd5b067f
    • 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
      Reintroduce compile-time --string-slices flag. · 781f7685
      Benedikt Meurer authored
      This partially reverts commit aaebbbaa,
      which removed the --string-slices flag. We reintroduce the flag as a
      build time flag for an experiment to gather information of how much
      SliceStrings help with throughput and effective memory use.
      
      Bug: v8:7025
      Change-Id: I529da91bb7501fe93d83891abf560710f3ecb9d0
      Reviewed-on: https://chromium-review.googlesource.com/750681Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49068}
      781f7685
    • 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
  2. 01 Nov, 2017 5 commits
  3. 31 Oct, 2017 18 commits
  4. 30 Oct, 2017 7 commits