1. 07 Mar, 2019 1 commit
  2. 25 Feb, 2019 1 commit
    • Ross McIlroy's avatar
      [Runtime] Ensure template objects are retained if bytecode is flushed. · ec9aef3d
      Ross McIlroy authored
      Template objects should be cached after they are first created and reused on
      subsiquent calls to tag functions. Currently these cached objects are stored
      on the feedback vector, which has appropriate lifetime, however with bytecode
      flushing the feedback vector could be cleared when the bytecode is flushed,
      causing the template object to be dropped.
      
      In order to retain the cached template objects in the face of bytecode flushing,
      this CL adds a weakmap for each native context that is (weakly) keyed by
      shared function info, and holds a linked list of cached template objects
      associated with that shared function info, indexed by feedback vector slot id.
      Misses will check this weakmap, and if no entry is found, a new template object
      is created and added into this weakmap alongside the feedback vector.
      
      BUG=v8:8799,v8:8799,v8:8395
      
      Change-Id: Ia95d5cfc394ce58dc9fe6a1e49780f05299acc17
      Reviewed-on: https://chromium-review.googlesource.com/c/1477746
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59818}
      ec9aef3d
  3. 14 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce a CallFunctionTemplate builtin. · a2d9924c
      Benedikt Meurer authored
      When calling into API callbacks from TurboFan optimized, we can
      currently only take a fast-path when TurboFan is able to find some
      information about the receiver in the graph, or when the API callback
      specifies that it neither requires an access check (aka "accepts any
      receiver") nor an interface check (aka "compatible receiver check").
      
      This change introduces a new CallFunctionTemplate builtin that sits
      in front of the CallApiCallback builtin and does both the access as well
      as the interface check as necessary (and raises appropriate exceptions).
      This way TurboFan can still call into the API callback via the fast-path
      even without ahead knowledge about the receiver, which is significantly
      faster than the generic call machinery for API callbacks.
      
      On the test case from the Angular team[1], the interesting metrics
      improve from
      
        DOM_mono: 0.273 ms
        DOM_mega: 0.571 ms
        DOM_call: 0.649 ms
      
      to
      
        DOM_mono: 0.264 ms
        DOM_mega: 0.572 ms
        DOM_call: 0.368 ms
      
      so the DOM_call is only about **1.4 times slower** than the DOM_mono and
      about **1.5 times faster** than the DOM_mega case (compared to **2.4
      times slower**). Execution time in the DOM_call was reduced by around
      **~45%**.
      
      Currently this new code path is limited to TurboFan optimized code, but
      the idea is to eventually migrate the API calls from baseline to also
      use the new CSA functionality, but there are lot's of subleties to take
      into account, so starting with small changes to get coverage for the
      basic building blocks.
      
      [1]: https://mhevery.github.io/perf-tests/DOM-megamorphic.html
      
      Bug: v8:8820
      Change-Id: Ie1029cf182ce05a6e519fd9a9d4fa825db8adb4c
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/1470129
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59598}
      a2d9924c
  4. 13 Feb, 2019 1 commit
  5. 11 Feb, 2019 1 commit
  6. 02 Feb, 2019 1 commit
  7. 22 Jan, 2019 1 commit
  8. 18 Jan, 2019 1 commit
  9. 10 Jan, 2019 1 commit
    • Leszek Swirski's avatar
      [destructuring] Get non-coercible message contents in runtime · 5e2c23e2
      Leszek Swirski authored
      For desrtucturing assignments from null/undefined, we throw an error
      that references the destructuring object literal's property name, e.g.
      for
        var { x } = null;
      we report that we cannot destructure 'x' from null.
      
      Rather than calculating this property during bytecode generation (and
      including it in the bytecode as an argument to the type error
      constructor), we can calculate it at exception throwing time, by
      re-parsing the source in a similar way to the existing call site
      rendering.
      
      This slightly decreases bytecode size and slightly decreases the amount
      of work the bytecode compiler needs to do. In the future, it could also
      allow us to give more detailed error messages, as we now have access to
      the entire AST and are on the slow path anyway.
      
      Bug: v8:6499
      Change-Id: Icdbd4667db548b4e5e62ef97797a3771b5c1bf72
      Reviewed-on: https://chromium-review.googlesource.com/c/1396080Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58706}
      5e2c23e2
  10. 09 Jan, 2019 1 commit
  11. 07 Jan, 2019 1 commit
    • peterwmwong's avatar
      [js] Remove CORE JS Natives (prologue.js), port extra utils to C++/Torque · 263dce9b
      peterwmwong authored
      - Removes the last `CORE` JS native script: `prologue.js`.
      - Removes build step and bootstrapping associated with building/loading `CORE` JS natives.
      - Removes `natives_utils_object` from context.
      - Deprecates `--expose-natives-as` flag.
      - Ports extra utils functions to C++ (`uncurryThis`) or Torque
        (`createPrivateSymbol`, `markPromiseAsHandled`, and `promiseState`).
      - Move extra utils constants initialization into bootstrapper
        (`kPROMISE_PENDING`, `kPROMISE_FULFILLED`, `kPROMISE_REJECTED`).
      - Removes unused extra utils functions `log` and `logStackTrace`.
      
      Drive-by: Added test coverage for Array#includes being an unscopeable.
      
      Bug: v8:7624
      Change-Id: I5d983f8d11b76cb4dd3c2c67592ce1dc88364cd9
      Reviewed-on: https://chromium-review.googlesource.com/c/1381672Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
      Cr-Commit-Position: refs/heads/master@{#58577}
      263dce9b
  12. 20 Dec, 2018 1 commit
  13. 04 Dec, 2018 1 commit
  14. 13 Nov, 2018 1 commit
  15. 12 Nov, 2018 1 commit
  16. 29 Oct, 2018 1 commit
  17. 11 Oct, 2018 1 commit
  18. 17 Sep, 2018 1 commit
  19. 05 Sep, 2018 1 commit
    • Hai Dang's avatar
      Reland "[interpreter] Add bytecode for leading array spreads." · 5f8a4272
      Hai Dang authored
      This is a reland of 1c48d52b.
      
      It turned out that IterableToList doesn't always behave according to
      the ES operation with the same name. Specifically, it allows holey arrays
      to take its fast path, which produces an output array with holes where
      actually "undefined" elements should appear.
      
      This CL changes the version of IterableToList that is used for spreads
      (IterableToListWithSymbolLookup) such that holey arrays take the slow path.
      It also includes tests for such situations.
      
      Original change's description:
      > [interpreter] Add bytecode for leading array spreads.
      >
      > This CL improves the performance of creating [...a, b] or [...a].
      > If the array literal has a leading spread, this CL emits the bytecode
      > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      > is implemented by [IterableToListDefault] builtin to create the initial
      > array for the leading spread. IterableToListDefault has a fast path to
      > clone efficiently if the spread is an actual array.
      >
      > The bytecode generated is now shorter. Bytecode generation is refactored
      > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      > from this optimization also.
      > For now, turbofan also lowers the bytecode to the builtin.
      >
      > The idiomatic use of [...a] to clone the array a now performs better
      > than a simple for-loop, but still does not match the performance of slice.
      >
      > Bug: v8:7980
      >
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      > Reviewed-on: https://chromium-review.googlesource.com/1181024
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Commit-Queue: Hai Dang <dhai@google.com>
      > Cr-Commit-Position: refs/heads/master@{#55520}
      
      Bug: v8:7980
      Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1201882
      Commit-Queue: Hai Dang <dhai@google.com>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55639}
      5f8a4272
  20. 03 Sep, 2018 1 commit
  21. 31 Aug, 2018 1 commit
    • Georg Neis's avatar
      Revert "[interpreter] Add bytecode for leading array spreads." · ef569028
      Georg Neis authored
      This reverts commit 1c48d52b.
      
      Reason for revert: Clusterfuzz found something.
      
      Original change's description:
      > [interpreter] Add bytecode for leading array spreads.
      > 
      > This CL improves the performance of creating [...a, b] or [...a].
      > If the array literal has a leading spread, this CL emits the bytecode
      > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      > is implemented by [IterableToListDefault] builtin to create the initial
      > array for the leading spread. IterableToListDefault has a fast path to
      > clone efficiently if the spread is an actual array.
      > 
      > The bytecode generated is now shorter. Bytecode generation is refactored
      > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      > from this optimization also.
      > For now, turbofan also lowers the bytecode to the builtin.
      > 
      > The idiomatic use of [...a] to clone the array a now performs better
      > than a simple for-loop, but still does not match the performance of slice.
      > 
      > Bug: v8:7980
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      > Reviewed-on: https://chromium-review.googlesource.com/1181024
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Commit-Queue: Hai Dang <dhai@google.com>
      > Cr-Commit-Position: refs/heads/master@{#55520}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com
      
      Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7980
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1199303Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55544}
      ef569028
  22. 30 Aug, 2018 1 commit
    • Hai Dang's avatar
      [interpreter] Add bytecode for leading array spreads. · 1c48d52b
      Hai Dang authored
      This CL improves the performance of creating [...a, b] or [...a].
      If the array literal has a leading spread, this CL emits the bytecode
      [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      is implemented by [IterableToListDefault] builtin to create the initial
      array for the leading spread. IterableToListDefault has a fast path to
      clone efficiently if the spread is an actual array.
      
      The bytecode generated is now shorter. Bytecode generation is refactored
      into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      from this optimization also.
      For now, turbofan also lowers the bytecode to the builtin.
      
      The idiomatic use of [...a] to clone the array a now performs better
      than a simple for-loop, but still does not match the performance of slice.
      
      Bug: v8:7980
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      Reviewed-on: https://chromium-review.googlesource.com/1181024Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Commit-Queue: Hai Dang <dhai@google.com>
      Cr-Commit-Position: refs/heads/master@{#55520}
      1c48d52b
  23. 03 Aug, 2018 1 commit
  24. 31 Jul, 2018 1 commit
  25. 25 Jul, 2018 3 commits
  26. 17 Jul, 2018 1 commit
  27. 03 Jul, 2018 1 commit
  28. 23 Jun, 2018 1 commit
  29. 20 Jun, 2018 1 commit
  30. 05 Jun, 2018 1 commit
  31. 03 Jun, 2018 1 commit
  32. 18 May, 2018 1 commit
  33. 02 May, 2018 1 commit
    • Leszek Swirski's avatar
      Revert "[parser] Slice the source string where possible" · 18bc2856
      Leszek Swirski authored
      This reverts commit 2df5e7a7.
      
      Reason for revert: Mystery crashes https://bugs.chromium.org/p/chromium/issues/detail?id=838805
      
      Original change's description:
      > [parser] Slice the source string where possible
      > 
      > When internalizing string literals (for quoted strings or property names),
      > try to create a sliced string of the source string rather than allocating
      > a copy of the bytes.
      > 
      > This will not work for string literals that contain escapes (e.g. unicode
      > escapes), and currently does not support two-byte strings.
      > 
      > Bug: chromium:818642
      > Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
      > Reviewed-on: https://chromium-review.googlesource.com/1010282
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52898}
      
      TBR=marja@chromium.org,yangguo@chromium.org,jarin@chromium.org,mlippautz@chromium.org,leszeks@chromium.org,verwaest@chromium.org
      
      Change-Id: I598b6668c43a3e843e2dd8e60852b2b2f3461954
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:818642
      Reviewed-on: https://chromium-review.googlesource.com/1039885
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52919}
      18bc2856
  34. 01 May, 2018 1 commit
  35. 09 Apr, 2018 1 commit
  36. 06 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored
      This reverts commit f9a2e24b.
      
      Reason for revert: gc stress failures not all fixed by follow up.
      
      Original change's description:
      > [cleanup] Refactor the Factory
      > 
      > There is no good reason to have the meat of most objects' initialization
      > logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      > this CL changes the protocol between Heap and Factory to be AllocateRaw,
      > and all object initialization work after (possibly retried) successful
      > raw allocation happens in the Factory.
      > 
      > This saves about 20KB of binary size on x64.
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      > Reviewed-on: https://chromium-review.googlesource.com/959533
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52416}
      
      TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
      
      Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored
      There is no good reason to have the meat of most objects' initialization
      logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      this CL changes the protocol between Heap and Factory to be AllocateRaw,
      and all object initialization work after (possibly retried) successful
      raw allocation happens in the Factory.
      
      This saves about 20KB of binary size on x64.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      Reviewed-on: https://chromium-review.googlesource.com/959533
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b
  37. 22 Mar, 2018 1 commit
    • Leszek Swirski's avatar
      Reland^2: Remove SFI code field · 51ded9d3
      Leszek Swirski authored
      This is a reland of d8f564ea
      
      TBR=mstarzinger@chromium.org,yangguo@chromium.org,jgruber@chromium.org
      
      Original change's description:
      > Reland: Remove SFI code field
      >
      > Remove the SharedFunctionInfo code field, inferring the code object
      > from the function_data field instead. In some cases, the function_data
      > field can now hold a Code object (e.g. some WASM cases).
      >
      > (Reland of https://chromium-review.googlesource.com/952452)
      >
      > TBR=mstarzinger@chromium.org
      >
      > Bug: chromium:783853
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      > Change-Id: I10ea5be7ceed1b51362a2fad9be7397624d69343
      > Reviewed-on: https://chromium-review.googlesource.com/970649
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52136}
      
      Bug: chromium:783853
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: I5187851b923e9a92f43daf8cb99e662786cbb839
      Reviewed-on: https://chromium-review.googlesource.com/975942
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52159}
      51ded9d3