1. 21 Aug, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtin] Further cleanup %ArrayIteratorPrototype%.next(). · 2650fc33
      Benedikt Meurer authored
      Refactor the ArrayIteratorPrototypeNext CSA builtin to handle the
      JSArray element access in a dedicated helper macro, very similar
      to how it's done for JSTypedArray's. Also add support for dictionary
      elements to this helper macro using the existing dictionary access
      logic in the CodeStubAssembler.
      
      This improves the readability of the builtin significantly and the
      performance of iterating arrays with dictionary elements goes up by
      a factor of ~3.5x.
      
      Bug: v8:8015, v8:8070
      Change-Id: Ibfee760ea1e4bc0fffb42b232fb1d097b706bd1f
      Reviewed-on: https://chromium-review.googlesource.com/1183305Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55283}
      2650fc33
  2. 20 Aug, 2018 1 commit
  3. 01 Aug, 2018 1 commit
    • Andreas Haas's avatar
      [mjsunit] Move the implementation of testAsync into a separate file · 8c3c1b6c
      Andreas Haas authored
      The original implementation of 'testAsync' in mjsunit.js required to
      put the call to '%AbortJS' into an 'eval' statement. The reason is that
      this call requires the flag --allow-natives-syntax to be set, but the
      flag is not set in all mjsunit tests. With the use of 'eval'
      compilation errors can be avoided.
      
      The problem with this approach was that the fuzzer started to produce
      test cases which include the line 'eval("%AbortJS(message)");', and
      this line crashes intentionally. Different to the line
      '%Abort(message)', however, the 'eval' statement cannot be filtered
      so easily in the fuzzer. Therefore I pulled the implementation of
      'testAsync' into a separate file to avoid the 'eval'.
      
      Additional changes: I use '===' now instead of 'deepEquals' in
      AsyncAssertion.equals because 'deepEquals' is not available outside
      mjsunit.js. Using '===' seems more appropriate anyways because for
      all tests but one it is sufficient, and it is more precise than
      deepEquals.
      
      R=gsathya@chromium.org
      
      Bug: chromium:774841
      Change-Id: I47270aa63ff5a1d6aa76a771f9276eaaf579c5ac
      Reviewed-on: https://chromium-review.googlesource.com/1156598Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54833}
      8c3c1b6c
  4. 27 Jul, 2018 1 commit
  5. 19 Jul, 2018 1 commit
  6. 18 Jul, 2018 1 commit
  7. 28 Jun, 2018 1 commit
    • Caitlin Potter's avatar
      [runtime] perform type conversion earlier in IntegerIndexedElementSet · 6c585ef0
      Caitlin Potter authored
      When storing an indexed property in a typed array, it's necessary to
      convert the value to a Number (or to a Bigint) before performing the
      bounds check, per
      https://tc39.github.io/ecma262/#sec-integerindexedelementset.
      
      This CL adds appropriate type conversions in
      Object::SetPropertyInternal (which technically is reached after the
      bounds check has already occurred, but this isn't observable yet ---
      In the future, once OOB accesses on TypedArrays actually throw, this
      will need to be refactored again), and in StoreFastElementStub, and
      ElementsTransitionAndStoreStub (via CSA::EmitElementStore).
      
      The change was not necessary in TurboFan, as
      JSNativeContextSpecialization already performs the value conversion
      before the boundscheck.
      
      The result is some fixed test262 tests, and some new test coverage
      for this behaviour in mjsunit.
      
      BUG=v8:7896, v8:5327
      R=neis@chromium.org, jkummerow@chromium.org, gsathya@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Ibe6bec24c72ef6a4fd3e77d5bcafa03737f4c5e3
      Reviewed-on: https://chromium-review.googlesource.com/1117372
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54096}
      6c585ef0
  8. 12 Jun, 2018 2 commits
  9. 11 Jun, 2018 1 commit
  10. 24 May, 2018 1 commit
    • Simon Zünd's avatar
      [typedarray] Change TypedArray.p.sort implementation. · a6c71508
      Simon Zünd authored
      This CL uses the new function pointers and generic features of Torque
      to improve the performance of TypedArray.p.sort.
      
      Instead of one Load/Store builtin that dispatches at runtime based on
      the element kind, there are now many small builtins (one for each
      element kind). The sorting algorithm then uses function pointers to
      those small builtins, which get set once.
      
      Changes in the relevant benchmarks:
      
      Benchmark   Original (JS)   Current   This CL
      IntTypes             83.9     202.3     240.7
      BigIntTypes          32.1      47.2      53.3
      FloatTypes           99.3     109.3     129.3
      
      Bug: v8:7382
      Change-Id: I8684410524d546615b19f6edcbfdc615068196aa
      Reviewed-on: https://chromium-review.googlesource.com/1070069
      Commit-Queue: Simon Zünd <szuend@google.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53322}
      a6c71508
  11. 07 May, 2018 1 commit
  12. 02 May, 2018 1 commit
  13. 30 Apr, 2018 1 commit
  14. 29 Apr, 2018 1 commit
  15. 27 Apr, 2018 1 commit
  16. 23 Apr, 2018 3 commits
  17. 20 Apr, 2018 1 commit
  18. 26 Mar, 2018 1 commit
  19. 23 Mar, 2018 1 commit
  20. 22 Mar, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Reduce resolve element closure overhead in Promise.all. · d8658177
      Benedikt Meurer authored
      In Promise.all we used to allocate a fresh closure plus a fresh context
      for each individual element, which is quite a lot of overhead, especially
      since this could be shared in a single context for all elements. The only
      bit of information that is needed for each resolve element closure is the
      index under which to store the resulting value. With this change we move
      this index to the "identity hash" field of the JSFunction, which doesn't
      care about the concrete value anyways, as long as it's not zero (the "no
      hash" sentinel), and share the rest of the fields in a single outer
      context for all resolve element closures.
      
      This limits the maximum number of elements for Promise.all to 2^21 for
      now, but that should be fine. Shall we ever see the need for more than
      this, we can add machinery to overflow to separate context for indices
      larger than 2^21.
      
      This significantly reduces the overhead due to Promise.all on the
      parallel-async-es2017-native test, with execution time dropping from
      around 148ms to 133ms, so overall a steady 10% improvement on this
      benchmark.
      
      Bug: v8:7253
      Change-Id: I1092da771c4919f3db7129d2b0a244fc26a7b144
      Reviewed-on: https://chromium-review.googlesource.com/973283Reviewed-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@{#52134}
      d8658177
  21. 14 Mar, 2018 1 commit
    • Caitlin Potter's avatar
      Reland "[esnext] re-implement template strings" · b8229612
      Caitlin Potter authored
      - Add a new bytecode for the ToString operation, replacing the old
      intrinsic call (currently does not collect type feedback).
      - Add a new AST node to represent TemplateLiterals, and avoid
      generating unnecessary ToString operations in some simple cases.
      - Use a single feedback slot for each string addition, because the
      type feedback should always be the same for each addition
      
      This seems to produce a very slight improvement on JSTests benchmarks
      and bench-ruben.js from v8:7415, and it's possible that type feedback
      for the ToString bytecode could provide more opportunities to eliminate
      the runtime call in TurboFan.
      
      Doesn't touch tagged templates
      
      [esnext] fix OOB read in ASTPrinter::VisistTemplateLiteral
      
      Fixes an error where TemplateLiteral printing in --print-ast
      would try to read an element beyond the length of a vector.
      
      BUG=v8:7415, chromium:820596
      R=adamk@chromium.org, gsathya@chromum.org, rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
      
      Change-Id: Ie56894f73a6445550a5f95f42160c4e29ab1da42
      Reviewed-on: https://chromium-review.googlesource.com/958408Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#51933}
      b8229612
  22. 13 Mar, 2018 1 commit
  23. 10 Mar, 2018 2 commits
  24. 02 Mar, 2018 1 commit
  25. 22 Feb, 2018 2 commits
    • Adam Klein's avatar
      ToString of a Proxied function should not throw · f7d7b5c6
      Adam Klein authored
      Without --harmony-function-tostring, anything other than a JSFunction
      or JSBoundFunction throw when Function.prototype.toString is called on
      them. But with the toString revision, anything callable allows toString
      (and for non-Functions returns the good old "function () { [native code] }"
      string).
      
      Bug: v8:7484
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: I3540e213a40992151761b59666fe36e0510da908
      Reviewed-on: https://chromium-review.googlesource.com/932825
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51489}
      f7d7b5c6
    • Peter Marshall's avatar
      [typedarray] Fix IterableToList when Number has an iterator · aaa78c33
      Peter Marshall authored
      IterableToListCanBeElided checked that the input was always a HeapObject
      but this is not true when an iterator symbol is defined on the Number
      prototype, meaning Smi and HeapNumber can also be passed in.
      
      Added a regression test for the crash and some correctness tests for
      smi and double input to TA.from.
      
      Also factored out the tests in typedarray-from.js that modify global
      state e.g. protector cells, so that one iteration of the top level
      loop does not interfere with the next.
      
      Bug: chromium:814643
      Change-Id: I364d11f011faf8370446f905a35a945d47e4477f
      Reviewed-on: https://chromium-review.googlesource.com/930962Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51461}
      aaa78c33
  26. 20 Feb, 2018 1 commit
  27. 19 Feb, 2018 2 commits
  28. 15 Feb, 2018 1 commit
  29. 14 Feb, 2018 1 commit
  30. 13 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Optimize PromiseResolveThenableJob for the common case. · 1f8dcc5d
      Benedikt Meurer authored
      The idea here is that in case the `thenable` is a JSPromise and `then`
      is the initial `Promise.prototype.then` method, and the @@species lookup
      chain is intact, we can skip creating the temporary promise and the
      closures (with the shared context), and instead directly call into our
      PerformPromiseThen. This is sound since - given above mentioned
      conditions - our short-cut
      
        PerformPromiseThen(thenable, undefined, undefined, promise_to_resolve)
      
      is not observably different from the actual
      
        resolve, reject = CreateResolvingFunctions(promise_to_resolve)
        result_capability = NewPromiseCapability(%Promise%)
        PerformPromiseThen(thenable, resolve, reject, result_capability)
      
      except through PromiseHooks (and potentially via the async stack
      traces). So we disable the fast-path if either promise hooks are enabled
      or the debugger is active for now.
      
      This improves the performance on the wikipedia benchmark by 20-25% and
      the bluebird-doxbee benchmark by around 20%.
      
      Bug: v8:7253
      Change-Id: I23c92ad365c2b71d65057573f2d8febe2afe00b0
      Reviewed-on: https://chromium-review.googlesource.com/911800
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51261}
      1f8dcc5d
  31. 12 Feb, 2018 2 commits
    • Camillo Bruni's avatar
      [runtime] Harden JSFunction::CalculateInstanceSizeHelper(...) · 7b27040e
      Camillo Bruni authored
      Bug: chromium:808192
      Change-Id: I80136d291d5c21c311903bffc96d86d109f5cdc9
      Reviewed-on: https://chromium-review.googlesource.com/902103
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51255}
      7b27040e
    • Caitlin Potter's avatar
      [esnext] implement spec change to TaggedTemplate callsite caching · d3ca0d00
      Caitlin Potter authored
      Implements the change outlined in https://github.com/tc39/ecma262/pull/890,
      which has been ratified and pulled into the specification. In particular,
      template callsite objects are no longer kept in a global, eternal Map, but
      are instead associated with their callsite, which can be collected. This
      prevents a memory leak incurred by TaggedTemplate calls.
      
      Changes, summarized:
      
          - Remove the TemplateMap and TemplateMapShape objects, instead caching
            template objects in the feedback vector.
          - Remove the `hash` member of TemplateObjectDescriptor, and the Equals
            method (used by TemplateMap)
          - Add a new FeedbackSlotKind (kTemplateObject), which behaves similarly
            to FeedbackSlotKind::kLiteral, but prevents eval caching. This ensures
            that a new feedback vector is always created for eval() containing tagged
            templates, even when the CompilationCache is used.
          - GetTemplateObject bytecode now takes a feedback index, and only calls
            into the runtime if the feedback is Smi::kZero (uninitialized).
      
      BUG=v8:3230, v8:2891
      R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org,
      rmcilroy@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I7827bc148d3d93e2b056ebf63dd624da196ad423
      Reviewed-on: https://chromium-review.googlesource.com/624564
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51248}
      d3ca0d00
  32. 09 Feb, 2018 1 commit
  33. 07 Feb, 2018 1 commit