1. 24 May, 2019 3 commits
    • Simon Zünd's avatar
      Reland "[array] Move Array#sort pre-processing to Torque" · 843b6646
      Simon Zünd authored
      This is a reland of 2b0ac2fb
      
      The layout test that caused this revert was fixed with:
      https://crrev.com/c/1627386
      
      Original change's description:
      > [array] Move Array#sort pre-processing to Torque
      >
      > This CL removes the "PrepareElementsForSort" runtime function, and
      > replaces it with a simpler version in Torque. The biggest difference
      > is that certain sparse configurations no longer have a fast-path.
      >
      > The Torque pre-processing step replaces the existing Torque mechanism that
      > copied already pre-processed elements into the "work" FixedArray. The Torque
      > compacting works as follows:
      >   - Iterate all elements from 0 to {length}
      >     - If the element is the hole: Do nothing.
      >     - If the element is "undefined": Increment undefined counter.
      >     - In all other cases, push the element into the "work" FixedArray.
      >
      > Then the "work" FixedArray is sorted as before. Writing the elements from
      > the "work" array back into the receiver, after sorting, has three steps:
      >   1. Copy the sorted elements from the "work" FixedArray to the receiver.
      >   2. Add previously counted number of "undefined" to the receiver.
      >   3. Depending on the backing store either delete properties or
      >      set them to the Hole up to {length}.
      >
      > Bug: v8:8714
      > Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61812}
      
      TBR: jgruber@chromium.org
      Bug: v8:8714
      Change-Id: If7613f6e5f37c5e0d649e8192195594bc6c32100
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627977
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Auto-Submit: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61827}
      843b6646
    • Simon Zünd's avatar
      Revert "[array] Move Array#sort pre-processing to Torque" · 70eeb22d
      Simon Zünd authored
      This reverts commit 2b0ac2fb.
      
      Reason for revert: Breaks scrollingcoordinator/non-fast-scrollable-region-nested.html layout test on https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064/32241 
      
      Original change's description:
      > [array] Move Array#sort pre-processing to Torque
      > 
      > This CL removes the "PrepareElementsForSort" runtime function, and
      > replaces it with a simpler version in Torque. The biggest difference
      > is that certain sparse configurations no longer have a fast-path.
      > 
      > The Torque pre-processing step replaces the existing Torque mechanism that
      > copied already pre-processed elements into the "work" FixedArray. The Torque
      > compacting works as follows:
      >   - Iterate all elements from 0 to {length}
      >     - If the element is the hole: Do nothing.
      >     - If the element is "undefined": Increment undefined counter.
      >     - In all other cases, push the element into the "work" FixedArray.
      > 
      > Then the "work" FixedArray is sorted as before. Writing the elements from
      > the "work" array back into the receiver, after sorting, has three steps:
      >   1. Copy the sorted elements from the "work" FixedArray to the receiver.
      >   2. Add previously counted number of "undefined" to the receiver.
      >   3. Depending on the backing store either delete properties or
      >      set them to the Hole up to {length}.
      > 
      > Bug: v8:8714
      > Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61812}
      
      TBR=peter.wm.wong@gmail.com,jgruber@chromium.org,tebbi@chromium.org,szuend@chromium.org
      
      Change-Id: If1c1bc07f38dfbd4bf6b6ce8f9d70714e7526877
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8714
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627976Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61814}
      70eeb22d
    • Simon Zünd's avatar
      [array] Move Array#sort pre-processing to Torque · 2b0ac2fb
      Simon Zünd authored
      This CL removes the "PrepareElementsForSort" runtime function, and
      replaces it with a simpler version in Torque. The biggest difference
      is that certain sparse configurations no longer have a fast-path.
      
      The Torque pre-processing step replaces the existing Torque mechanism that
      copied already pre-processed elements into the "work" FixedArray. The Torque
      compacting works as follows:
        - Iterate all elements from 0 to {length}
          - If the element is the hole: Do nothing.
          - If the element is "undefined": Increment undefined counter.
          - In all other cases, push the element into the "work" FixedArray.
      
      Then the "work" FixedArray is sorted as before. Writing the elements from
      the "work" array back into the receiver, after sorting, has three steps:
        1. Copy the sorted elements from the "work" FixedArray to the receiver.
        2. Add previously counted number of "undefined" to the receiver.
        3. Depending on the backing store either delete properties or
           set them to the Hole up to {length}.
      
      Bug: v8:8714
      Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61812}
      2b0ac2fb
  2. 23 May, 2019 1 commit
  3. 20 May, 2019 1 commit
  4. 15 May, 2019 3 commits
  5. 11 May, 2019 1 commit
  6. 07 May, 2019 1 commit
  7. 04 May, 2019 1 commit
    • Sergiy Belozorov's avatar
      [tools] Default to 4 retries for all perf tests · b3e2bcf9
      Sergiy Belozorov authored
      Overall, total test runtime that was wasted due to timeouts is 3420 seconds in
      the last 2 weeks. Even with 4 retries, assuming all of them time out, needed
      additional capacity is under 2 hours per week. Based on this analysis, I think
      it's safe to land this CL.
      
      Note that this is not intended as a long-term solution of the timeout problem,
      but rather a temporary solution to prevent ongoing errors. Proper investigation
      and correct long-term solution are still needed and tracked in the bug.
      
      R=machenbach@chromium.org, tmrts@chromium.org
      
      Bug: chromium:841700
      Change-Id: Id16e6b784fa85bb9e28ed8c6b267b583636e2dc1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593342Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61224}
      b3e2bcf9
  8. 30 Apr, 2019 1 commit
  9. 25 Apr, 2019 2 commits
  10. 16 Apr, 2019 1 commit
  11. 12 Apr, 2019 1 commit
  12. 25 Mar, 2019 1 commit
  13. 21 Mar, 2019 2 commits
  14. 20 Mar, 2019 1 commit
  15. 19 Mar, 2019 1 commit
  16. 18 Mar, 2019 1 commit
    • Simon Zünd's avatar
      [js-perf] Improve end of serialize StackTrace benchmark · 027c2677
      Simon Zünd authored
      The serialize set of microbenchmarks serializes Error.stack of a
      prepared set of error objects. When all objects have been serialized,
      the benchmark then wrapped around and only accessed the resulting
      string properties. This, of course, is a lot faster and benchmark
      results are heavily fluctuating when the end is reached.
      
      This CL fixes this by introducing a payload that should be similiar
      to the specific workload, which is executed after the end is reached.
      
      R=petermarshall@chromium.org
      
      Bug: v8:8742
      Change-Id: I7183d04e7c06af0c16fe3412e902f0d33605bc25
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1524485Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60297}
      027c2677
  17. 12 Mar, 2019 1 commit
  18. 06 Mar, 2019 1 commit
  19. 05 Mar, 2019 1 commit
  20. 04 Mar, 2019 1 commit
  21. 20 Feb, 2019 1 commit
  22. 15 Feb, 2019 1 commit
    • Frank Tang's avatar
      [Intl] Add String toLocale(Lower|Upper)Case perf benchmark · 889769b4
      Frank Tang authored
      $ python -u tools/run_perf.py --binary-override-path   out/x64.release/d8 --filter "JSTests/Strings/StringToLocaleCase"  test/js-perf-test/JSTests.json
      INFO      >>> Running suite: JSTests/Strings/StringToLocaleCase
      INFO      >>> Stdout (#1):
      StringToLocaleUpperCaseTR-Strings(Score): 622
      StringToLocaleLowerCaseTR-Strings(Score): 728
      StringToLocaleUpperCase-Strings(Score): 1129
      StringToLocaleLowerCase-Strings(Score): 1548
      
      Bug: v8:8839
      Change-Id: I35e20c84614e99cb84ae51c175ac6b1cd53ad3a6
      Reviewed-on: https://chromium-review.googlesource.com/c/1469327
      Commit-Queue: Frank Tang <ftang@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59615}
      889769b4
  23. 14 Feb, 2019 1 commit
    • Frank Tang's avatar
      [Intl] Performance benchmark for String.normalize · e15586e7
      Frank Tang authored
      $ python -u tools/run_perf.py --binary-override-path   out/x64.release/d8 --filter "JSTests/Strings/StringNormalize"  test/js-perf-test/JSTests.json
      INFO      >>> Running suite: JSTests/Strings/StringNormalize
      INFO      >>> Stdout (#1):
      StringNormalize-Strings(Score): 4014
      StringNormalizeNFD-Strings(Score): 742
      StringNormalizeNFKC-Strings(Score): 3066
      StringNormalizeNFKD-Strings(Score): 739
      
      Bug: v8:8844
      Change-Id: Ic941bafa82cead9cd0110ad7ac46e528d481189b
      Reviewed-on: https://chromium-review.googlesource.com/c/1470964
      Commit-Queue: Frank Tang <ftang@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59612}
      e15586e7
  24. 11 Feb, 2019 1 commit
    • Mythri's avatar
      Fix JSTest/Proxies/Set.*Trap tests to return true from the trap · 58ebbf34
      Mythri authored
      The spec specifies that a non-true return values from the trap functions
      should be treated as error in the strict mode. With the new lazy feedback
      effort inferring the language mode is expensive and causes regression on
      these tests. Since the test doesn't actually need to test this, fixing
      them to return true would help test the performance of calling the trap
      without the unnecessary overhead of inferring the language mode.
      
      Bug: chromium:925289
      Change-Id: Ib650c3210ee260296257ae3b56174099a5492675
      Reviewed-on: https://chromium-review.googlesource.com/c/1462959
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59505}
      58ebbf34
  25. 09 Feb, 2019 1 commit
  26. 07 Feb, 2019 1 commit
    • Frank Tang's avatar
      [Intl] Add perf test for Intl constructors · 151a0afb
      Frank Tang authored
      Just add tests so we can observe the number first.
      
      Got the following results
      $ python -u tools/run_perf.py --binary-override-path   out/x64.release/d8 --filter "JSTests/Intl"   test/js-perf-test/JSTests.json
      INFO      >>> Running suite: JSTests/Intl
      INFO      >>> Stdout (#1):
      NewIntlCollator-Intl(Score): 161
      NewIntlDateTimeFormat-Intl(Score): 9.73
      NewIntlNumberFormat-Intl(Score): 18.6
      NewIntlPluralRules-Intl(Score): 18.5
      NewIntlListFormat-Intl(Score): 19.4
      NewIntlRelativeTimeFormat-Intl(Score): 18.7
      
      Bug: chromium:928098
      Change-Id: I59f28393af8f868de639dcb81a7b2f69ce2f0eba
      Reviewed-on: https://chromium-review.googlesource.com/c/1455717
      Commit-Queue: Frank Tang <ftang@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59424}
      151a0afb
  27. 17 Jan, 2019 1 commit
  28. 10 Jan, 2019 2 commits
  29. 17 Dec, 2018 1 commit
  30. 14 Dec, 2018 1 commit
    • Jakob Kummerow's avatar
      Make RegExpFlagsFromString faster · 2cce5c52
      Jakob Kummerow authored
      The new ObjectPtr design makes non-inlined helper functions a little
      more expensive because "this" is always a pointer where pass-by-value
      would be more efficient, which is an issue for functions whose size puts
      them right at the threshold of getting inlined or not. String::Get falls
      into this category when called from RegExpFlagsFromString. In this case,
      we can do even better than restoring inlineability by fine-tuning
      the control flow a bit.
      
      This should repair the regression in crbug.com/910573
      
      Bug: chromium:910573
      Change-Id: Ie6b68ef01cd978ec502d8d6c1da788c77422dce7
      Reviewed-on: https://chromium-review.googlesource.com/c/1369087
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58234}
      2cce5c52
  31. 11 Dec, 2018 1 commit
  32. 06 Dec, 2018 1 commit
    • tzik's avatar
      Replace %RunMicrotasks with %PerformMicrotaskCheckpoint · 07011cc4
      tzik authored
      This replaces Runtime_RunMicrotasks with Runtime_PerformMicrotaskCheckpoint.
      
      RunMicrotasks forcibly runs Microtasks even when the microtasks are suppressed,
      and may causes nested Microtasks in a problematic way. E.g. that confuses
      v8::MicrotasksScope::IsRunningMicrotasks() and GetEnteredOrMicrotaskContext().
      
      OTOH, PerformMicrotaskCheckpoint() doesn't run cause the failure as it
      respects the microtask suppressions.
      
      As all existing tests don't call RunMicrotasks() in the suppressed situation
      (like Promise.resolve().then(()=>{%RunMicrotasks();})), this change should
      not affect to these tests.
      
      Change-Id: Ib043a0cc8e482e022d375084d65ea98a6f54ef3d
      Reviewed-on: https://chromium-review.googlesource.com/c/1360095Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58068}
      07011cc4
  33. 07 Nov, 2018 1 commit
    • Frank Tang's avatar
      [Intl] Add benchmark for toLocaleString/localeCompare · e23e1311
      Frank Tang authored
      This is a bit of a performance bottleneck currently and
      we're planning on improving performance by adding caching.
      These benchmarks will allow us to measure the improvements
      Add benchmark tests for
       String.prototype.localeCompare()
       Date.prototype.toLocaleString()
       Date.prototype.toLocaleDateString()
       Date.prototype.toLocaleTimeString()
       Number.prototype.toLocaleString()
      
      Run with
      python -u tools/run_perf.py --binary-override-path \
        out/x64.release/d8 --filter "JSTests/Strings/StringLocaleCompare" \
        test/js-perf-test/JSTests.json
      python -u tools/run_perf.py --binary-override-path \
        out/x64.release/d8 --filter "JSTests/Dates" \
        test/js-perf-test/JSTests.json
      python -u tools/run_perf.py --binary-override-path \
        out/x64.release/d8 --filter "JSTests/Numbers" \
        test/js-perf-test/JSTests.json
      
      Before the landing of dffaff77
      
       git reset --hard 474a6d63
      got
      StringLocaleCompare-Strings(Score): 13240000
      toLocaleDateString-Dates(Score): 1877000
      toLocaleString-Dates(Score): 1197000
      toLocaleTimeString-Dates(Score): 2147000
      toLocaleDateString-Dates(Score): 1908000
      
      After the landing of dffaff77
       git reset --hard dffaff77
      got
      StringLocaleCompare-Strings(Score): 97182
      toLocaleDateString-Dates(Score): 10436
      toLocaleString-Dates(Score): 10436
      toLocaleTimeString-Dates(Score): 10669
      toLocaleString-Numbers(Score): 2876
      
      
      Bug: chromium:901748
      Change-Id: Ibfea85fe668f1bfaacb2dfe08368cd920d2bbfc6
      Reviewed-on: https://chromium-review.googlesource.com/c/1318099Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Frank Tang <ftang@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57323}
      e23e1311