1. 07 Jan, 2018 1 commit
  2. 19 Dec, 2017 1 commit
  3. 15 Dec, 2017 2 commits
  4. 05 Dec, 2017 1 commit
  5. 29 Nov, 2017 2 commits
  6. 28 Nov, 2017 1 commit
  7. 14 Nov, 2017 1 commit
  8. 02 Nov, 2017 1 commit
  9. 30 Oct, 2017 1 commit
    • peterwmwong's avatar
      [builtins] Port WeakMap.p.set and WeakSet.p.add to CSA from JS · 7ae0a2f9
      peterwmwong authored
      - Add WeakMapPrototypeSet and WeakSetPrototypeAdd TFJ builtins
        - Fast paths for...
          1) existing key
          2) new key when ObjectHashTable has a "sufficient capacity"
      - Create WeakCollectionsBuiltinsAssembler to consolidate common WeakMap/WeakSet code generation
      - Convert existing WeakMapLookupHashIndex to use WeakCollectionsBuiltinsAssembler
      
      Some quick benchmarks shows performance gains of...
      - 1.56x - 1.98x for WeakMap constructor
      - 1.66x - 2.06x for WeakSet constructor
      - 1.50x - 2.11x for WeakMap.p.set
      - 1.54x - 2.26x for WeakSet.p.add
      
      https: //github.com/peterwmwong/v8-perf/blob/master/weakcollection-set/README.md
      Bug: v8:5049, v8:6604
      Change-Id: I3499d46be6b2b3b1d8d46720ebe86cc5142ee542
      Reviewed-on: https://chromium-review.googlesource.com/737935
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49036}
      7ae0a2f9
  10. 20 Oct, 2017 2 commits
  11. 19 Oct, 2017 2 commits
    • Jungshik Shin's avatar
      Intl.DateTimeFormat: throw RangeError for non-finite input · 831bc233
      Jungshik Shin authored
      intl.js throws an exception when datetime-value to format is
      Infinity or NaN, but there was a way to thwart the check.
      
      Moreover, intl.js and runtime-intl.cc have unnecessary conversions
      of 'Number->Date->Number'. I removed the unnecessary conversion
      and made 'Number' be passed to %InternalDateFormat.  With this
      streamlining, the work-around mentioned above does not work
      anymore.
      
      Add a check in runtime_intl.cc for Infinity/NaN and throw a
      RangeError.
      
      Add invalid-time test for invalid datetime-values passed to
      Intl.DateTimeFormat.format().
      
      Bug: chromium:774833
      Test: intl/date-format/invalid-time.js
      Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
      Change-Id: Idc575e532a86ee110dc4bb945ae023d6516650ee
      Reviewed-on: https://chromium-review.googlesource.com/724860
      Commit-Queue: Jungshik Shin <jshin@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48765}
      831bc233
    • peterwmwong's avatar
      [builtins] Port String.raw to CPP · 84c9f05d
      peterwmwong authored
      - Add StringRaw CPP Builtin
      - Remove string.js
      
      Bug: v8:5049
      Change-Id: I0d067c5b5aa9231383c2f9f2a9cf80f478fbbaa8
      Reviewed-on: https://chromium-review.googlesource.com/727723Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48748}
      84c9f05d
  12. 17 Oct, 2017 1 commit
  13. 16 Oct, 2017 1 commit
    • peterwmwong's avatar
      [builtins] Port String.prototype.{padStart, padEnd} to CSA · 33b23529
      peterwmwong authored
      - Extract core StringPrototypeRepeat code into a TFS builtin (StringRepeat)
        - Assumes arguments are a string and smi (no range checks)
      - Add StringPrototypePadStart and StringPrototypePadEnd TFJ builtins
        - Added StringPadAssembler to ensure common behavior
      - Removed functionality from string.js
      
      A quick benchmark shows significant performance gains for unoptimized
      code (2.1x to 2.46x) and optimized code (1.03x - 1.56x).
      
      https: //github.com/peterwmwong/v8-perf/blob/master/string-pad/README.md
      Bug: v8:5049
      Change-Id: I6e4fe99fb62a3edb3d6906fd4f78b3576b5b0d13
      Reviewed-on: https://chromium-review.googlesource.com/720067
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48595}
      33b23529
  14. 12 Oct, 2017 1 commit
  15. 11 Oct, 2017 1 commit
  16. 02 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Optimize TypedArray.prototype[Symbol.toStringTag]. · b8b76eba
      Benedikt Meurer authored
      The TypedArray.prototype[Symbol.toStringTag] getter is currently the best (and
      as far as I can tell only definitely side-effect free) way to check whether an
      arbitrary object is a TypedArray - either generally TypedArray or a specific
      one like Uint8Array. Using the getter is thus emerging as the general pattern
      to detect TypedArrays, even Node.js now adapted it starting with
      
        https://github.com/nodejs/node/pull/15663
      
      for the isTypedArray and isUint8Array type checks in lib/internal/util/types.js
      now.
      
      The getter returns either the string with the TypedArray subclass name
      (i.e. "Uint8Array") or undefined if the receiver is not a TypedArray.
      This can be implemented with a simple elements kind dispatch, instead of
      checking the instance type and then loading the class name from the
      constructor, which requires a loop walking up the transition tree. This
      CL ports the builtin to CSA and TurboFan, and changes the logic to a
      simple elements kind check. On the micro-benchmark mentioned in the
      referenced bug, the time goes from
      
        testIsArrayBufferView: 565 ms.
        testIsTypedArray: 2403 ms.
        testIsUint8Array: 3847 ms.
      
      to
      
        testIsArrayBufferView: 566 ms.
        testIsTypedArray: 965 ms.
        testIsUint8Array: 965 ms.
      
      which presents an up to 4x improvement.
      
      Bug: v8:6874
      Change-Id: I9c330b4529d9631df2f052acf023c6a4fae69611
      Reviewed-on: https://chromium-review.googlesource.com/695021Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48254}
      b8b76eba
  17. 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
  18. 16 Sep, 2017 1 commit
  19. 15 Sep, 2017 2 commits
  20. 13 Sep, 2017 1 commit
  21. 07 Sep, 2017 1 commit
  22. 06 Sep, 2017 2 commits
  23. 01 Sep, 2017 1 commit
  24. 31 Aug, 2017 1 commit
  25. 24 Aug, 2017 1 commit
  26. 21 Aug, 2017 2 commits
  27. 18 Aug, 2017 2 commits
  28. 17 Aug, 2017 1 commit
  29. 16 Aug, 2017 2 commits
  30. 14 Aug, 2017 1 commit
  31. 09 Aug, 2017 1 commit
    • Sathya Gunasekaran's avatar
      Revert "[runtime] Store hash code in length field" · 35f149e1
      Sathya Gunasekaran authored
      This reverts commit decf5750.
      
      Reason for revert: broken layout tests
      
      Original change's description:
      > [runtime] Store hash code in length field
      > 
      > Store the hash code in 21 bits of the length field.
      > 
      > Change the GetIdentityHash API to be unhandlified, since there's no
      > property lookup anymore.
      > 
      > Update js/ and test/ to match new API and expections.
      > 
      > Bug: 
      > Change-Id: I8dc75de4021f59e79b45f3f38ec997c3b3687b24
      > Reviewed-on: https://chromium-review.googlesource.com/589688
      > Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47259}
      
      TBR=ulan@chromium.org,jkummerow@chromium.org,mstarzinger@chromium.org,cbruni@chromium.org,gsathya@chromium.org
      
      Change-Id: I32db9c20a51b2401464924cafea502628a0d0b92
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/609322Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47260}
      35f149e1