1. 26 May, 2020 1 commit
  2. 24 Apr, 2020 1 commit
  3. 06 Feb, 2020 1 commit
  4. 15 Nov, 2019 1 commit
  5. 11 Oct, 2019 1 commit
  6. 10 Sep, 2019 1 commit
  7. 05 Sep, 2019 1 commit
    • Leszek Swirski's avatar
      Reland^2 "[ic] In-place Double -> Tagged transitions"" · 470e6857
      Leszek Swirski authored
      This is a reland of 981aafaf
      
      It adds double checks to LoadFieldByIndex in the optimizing compiler, which
      are likely the source of the crashes.
      
      Original change's description:
      > Reland "[ic] In-place Double -> Tagged transitions"
      >
      > This is a reland of 0736599a.
      > This is a reland of 7e1fbe8f.
      >
      > Original change description:
      > > [ic] In-place Double -> Tagged transitions
      > >
      > > With no more MutableHeapNumber, we can make Double -> Tagged transitions
      > > in-place, at the cost of an extra map check when accessing double fields
      > > to make sure they are still doubles.
      > >
      > > Bug: v8:9606
      > > Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#63374}
      >
      > TBR=verwaest@chromium.org, tebbi@chromium.org
      >
      > Bug: v8:9606
      > Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63499}
      
      TBR=verwaest@chromium.org
      
      Bug: v8:9606
      Bug: chromium:997989
      Change-Id: Iccfff8e5c6306c9ee4f6c62767dce883b1c6f743
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784288Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63582}
      470e6857
  8. 04 Sep, 2019 1 commit
    • Leszek Swirski's avatar
      Revert "Reland "[ic] In-place Double -> Tagged transitions"" · b293533e
      Leszek Swirski authored
      This reverts commit 981aafaf.
      
      Reason for revert: Still crashing on Canary.
      
      Original change's description:
      > Reland "[ic] In-place Double -> Tagged transitions"
      >
      > This is a reland of 0736599a.
      > This is a reland of 7e1fbe8f.
      >
      > Original change description:
      > > [ic] In-place Double -> Tagged transitions
      > >
      > > With no more MutableHeapNumber, we can make Double -> Tagged transitions
      > > in-place, at the cost of an extra map check when accessing double fields
      > > to make sure they are still doubles.
      > >
      > > Bug: v8:9606
      > > Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#63374}
      >
      > TBR=verwaest@chromium.org, tebbi@chromium.org
      >
      > Bug: v8:9606
      > Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63499}
      
      TBR=leszeks@chromium.org, verwaest@chromium.org, tebbi@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9606
      Bug: chromium:997989
      Change-Id: Ic95166e67df68e84a524dffd8155121c3ff6aa13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784283
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63550}
      b293533e
  9. 02 Sep, 2019 1 commit
  10. 29 Aug, 2019 1 commit
  11. 28 Aug, 2019 1 commit
    • Z Nguyen-Huu's avatar
      Add new nonextensible element kinds · 1f4bec27
      Z Nguyen-Huu authored
      Currently the backing store and elements kind might not aligned aka
      backing store can be dictionary where elements kind is frozen/sealed
      element kinds or the other way around. The reason is that
      Object.preventExtensions change elements kind to DICTIONARY while
      Object.seal/freeze change elements kind to SEALED/FROZEN element kind.
      Apply both these operations can lead to that problem as in
      chromium:992914
      
      To solve this issue, we avoid Object.preventExtensions to change backing
      store to dictionary by introducing new nonextensible elements kind.
      These new nonextensible elements kind are handled similar to frozen,
      sealed element kinds. This change not only fixes the problem but also
      optimize the performance of nonextensible objects.
      
      Change-Id: Iffc7f14eb48223c11abf3c577f305d2d072eb65b
      Bug: chromium:992914, v8:6831
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760976
      Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63432}
      1f4bec27
  12. 23 Aug, 2019 1 commit
  13. 20 Aug, 2019 1 commit
  14. 08 Jul, 2019 1 commit
  15. 24 Jun, 2019 1 commit
  16. 19 Jun, 2019 2 commits
  17. 11 Jun, 2019 1 commit
  18. 24 May, 2019 1 commit
  19. 23 May, 2019 4 commits
  20. 22 May, 2019 1 commit
  21. 20 May, 2019 1 commit
  22. 07 May, 2019 2 commits
  23. 29 Apr, 2019 2 commits
  24. 27 Apr, 2019 1 commit
  25. 12 Apr, 2019 2 commits
    • Benedikt Meurer's avatar
      [map] Support in-place field representation changes. · f11ba854
      Benedikt Meurer authored
      This adds a new flag --modify-field-representation-inplace (enabled by
      default), which lets the runtime perform field representation changes
      for Smi to Tagged or for HeapObject to Tagged in-place instead of
      creating new maps and marking the previous map tree as deprecated.
      
      That means we create (a lot) fewer Maps and DescriptorArrays in the
      beginning and also need to self-heal fewer objects later (migrating
      off the deprecated maps). In TurboFan we just take the "field owner
      dependency" whenever we use the field representation, which is very
      similar to what we already do for the field types. That means if we
      change the representation of a field that we used in optimized code,
      we will simply deoptimize that code and have TurboFan potentially
      later optimize it again with the new field representation.
      
      On the Speedometer2/ElmJS-TodoMVC test, this reduces the total execution
      time from around 415ms to around 352ms, which corresponds to a **15%**
      improvement. The overall Speedometer2 score improves from around 74.1
      to around 78.3 (on local runs with content_shell), corresponding to a
      **5.6%** improvement here. :tada:
      
      On the CNN desktop browsing story, it seems that we reduce map space
      utilization/fragmentation by about 4-5%. But since we allocate a lot
      less (fewer Maps and DescriptorArrays) we also significantly change
      the GC timing, which heavily influences the results here. So take this
      with a grain of salt. :shrug:
      
      Note: For Double fields, this doesn't change anything, meaning they
      still create new maps and deprecate the previous map trees.
      
      Bug: v8:8749, v8:8865, v8:9114
      Change-Id: Ibd70efcb59be982863905663dbfaa89aa5b31e14
      Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      Doc: http://bit.ly/v8-in-place-field-representation-changes
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565891
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60822}
      f11ba854
    • Michael Hablich's avatar
      Revert "[map] Support in-place field representation changes." · 48efe388
      Michael Hablich authored
      This reverts commit 1416d5a5.
      
      Reason for revert: blocks roll https://chromium-review.googlesource.com/c/chromium/src/+/1564550
      
      Original change's description:
      > [map] Support in-place field representation changes.
      > 
      > This adds a new flag --modify-field-representation-inplace (enabled by
      > default), which lets the runtime perform field representation changes
      > for Smi to Tagged or for HeapObject to Tagged in-place instead of
      > creating new maps and marking the previous map tree as deprecated.
      > 
      > That means we create (a lot) fewer Maps and DescriptorArrays in the
      > beginning and also need to self-heal fewer objects later (migrating
      > off the deprecated maps). In TurboFan we just take the "field owner
      > dependency" whenever we use the field representation, which is very
      > similar to what we already do for the field types. That means if we
      > change the representation of a field that we used in optimized code,
      > we will simply deoptimize that code and have TurboFan potentially
      > later optimize it again with the new field representation.
      > 
      > On the Speedometer2/ElmJS-TodoMVC test, this reduces the total execution
      > time from around 415ms to around 352ms, which corresponds to a **15%**
      > improvement. The overall Speedometer2 score improves from around 74.1
      > to around 78.3 (on local runs with content_shell), corresponding to a
      > **5.6%** improvement here. :tada:
      > 
      > On the CNN desktop browsing story, it seems that we reduce map space
      > utilization/fragmentation by about 4-5%. But since we allocate a lot
      > less (fewer Maps and DescriptorArrays) we also significantly change
      > the GC timing, which heavily influences the results here. So take this
      > with a grain of salt. :shrug:‍♂️
      > 
      > Note: For Double fields, this doesn't change anything, meaning they
      > still create new maps and deprecate the previous map trees.
      > 
      > Bug: v8:8749, v8:8865, v8:9114
      > Change-Id: I694a53f87ae5caeb868fd98a21809b66d4297d35
      > Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      > Doc: http://bit.ly/v8-in-place-field-representation-changes
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561132
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#60764}
      
      TBR=jarin@chromium.org,neis@chromium.org,ishell@chromium.org,bmeurer@chromium.org,verwaest@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:8749, v8:8865, v8:9114
      Change-Id: I666975d08d51bbe7ab4faec9428b9a1f88e9b322
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564208Reviewed-by: 's avatarMichael Hablich <hablich@chromium.org>
      Commit-Queue: Michael Hablich <hablich@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60807}
      48efe388
  26. 11 Apr, 2019 2 commits
    • Igor Sheludko's avatar
      [ic] Fix handling of +0/-0 when constant field tracking is enabled · 94c87fe0
      Igor Sheludko authored
      ... and ensure that runtime behaviour is in sync with the IC code.
      
      Bug: chromium:950747, v8:9113
      Change-Id: Ied66c9514cbe3a4d75fc71d4fc3b19ea1538f9b2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561319Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60768}
      94c87fe0
    • Benedikt Meurer's avatar
      [map] Support in-place field representation changes. · 1416d5a5
      Benedikt Meurer authored
      This adds a new flag --modify-field-representation-inplace (enabled by
      default), which lets the runtime perform field representation changes
      for Smi to Tagged or for HeapObject to Tagged in-place instead of
      creating new maps and marking the previous map tree as deprecated.
      
      That means we create (a lot) fewer Maps and DescriptorArrays in the
      beginning and also need to self-heal fewer objects later (migrating
      off the deprecated maps). In TurboFan we just take the "field owner
      dependency" whenever we use the field representation, which is very
      similar to what we already do for the field types. That means if we
      change the representation of a field that we used in optimized code,
      we will simply deoptimize that code and have TurboFan potentially
      later optimize it again with the new field representation.
      
      On the Speedometer2/ElmJS-TodoMVC test, this reduces the total execution
      time from around 415ms to around 352ms, which corresponds to a **15%**
      improvement. The overall Speedometer2 score improves from around 74.1
      to around 78.3 (on local runs with content_shell), corresponding to a
      **5.6%** improvement here. :tada:
      
      On the CNN desktop browsing story, it seems that we reduce map space
      utilization/fragmentation by about 4-5%. But since we allocate a lot
      less (fewer Maps and DescriptorArrays) we also significantly change
      the GC timing, which heavily influences the results here. So take this
      with a grain of salt. :shrug:‍♂️
      
      Note: For Double fields, this doesn't change anything, meaning they
      still create new maps and deprecate the previous map trees.
      
      Bug: v8:8749, v8:8865, v8:9114
      Change-Id: I694a53f87ae5caeb868fd98a21809b66d4297d35
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Doc: http://bit.ly/v8-in-place-field-representation-changes
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561132
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60764}
      1416d5a5
  27. 10 Apr, 2019 1 commit
  28. 08 Apr, 2019 1 commit
  29. 27 Feb, 2019 1 commit
  30. 06 Feb, 2019 1 commit
  31. 01 Feb, 2019 1 commit
    • Jaroslav Sevcik's avatar
      Map update for integrity level transitions. · 06ba822e
      Jaroslav Sevcik authored
      This adds support for integrity level transitions (preventExtensions,
      seal and freeze) to MapUpdater and Map::TryUpdate.
      
      In both cases, we first try to detect whether there were integrity
      level transitions in the transition tree to the old map and make note
      of the most restrictive integrity transition and the map just before
      the transition (integrity-source-map). Then we find an appropriate root
      (based on integrity-source-map's elements kind) and replay the
      transitions based on the integrity-source-map's descriptor
      array. Finally, if we saw an integrity level transition in
      the beginning, we will find-or-create that transition (on the
      updated version of integrity-source-map).
      
      For the following micro-benchmark, we get about 10x speedup.
      
      ```
      function C() {
        this.x = 1;
        Object.seal(this);
        this.x = 0.1;
      }
      
      const start = Date.now();
      for (let i = 0; i < 1e7; i++) {
        new C();
      }
      console.log("Reconfigure sealed: " + (Date.now() - start));
      ```
      
      Before:
      > Reconfigure sealed: 5202
      
      After:
      > Reconfigure sealed: 479
      
      Bug: v8:8538
      Change-Id: If695be7469d8b6ccd44ac4528be8aa34b65b3e4d
      Reviewed-on: https://chromium-review.googlesource.com/c/1442640
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59295}
      06ba822e
  32. 31 Jan, 2019 1 commit