1. 27 Apr, 2019 1 commit
  2. 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
  3. 11 Apr, 2019 1 commit
    • 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
  4. 04 Apr, 2019 1 commit
  5. 27 Feb, 2019 1 commit
  6. 21 Feb, 2019 2 commits
  7. 18 Jan, 2019 1 commit
  8. 26 Dec, 2018 1 commit
  9. 07 Dec, 2018 1 commit
  10. 05 Nov, 2018 1 commit
  11. 11 Sep, 2018 1 commit
  12. 29 May, 2018 1 commit
  13. 08 Mar, 2018 1 commit
  14. 13 Dec, 2017 1 commit
  15. 18 Oct, 2017 1 commit
  16. 12 Oct, 2017 1 commit
  17. 26 Sep, 2017 2 commits
  18. 22 Jun, 2017 1 commit
  19. 20 Apr, 2017 1 commit
  20. 10 Feb, 2017 1 commit
  21. 19 Jan, 2017 1 commit
  22. 16 Jan, 2017 1 commit
  23. 13 Jan, 2017 1 commit
  24. 12 Jan, 2017 2 commits
  25. 10 Jan, 2017 1 commit
  26. 05 Sep, 2016 1 commit
  27. 07 Jul, 2016 1 commit
    • ishell's avatar
      [runtime] Better encapsulation of dictionary objects handling in lookup iterator. · 3fbb4521
      ishell authored
      Now LookupIterator follows the same pattern of prepare transition, apply transition
      and write value when adding new properties to dictionary objects.
      
      JSGlobalObject case:
      * Prepare transition phase ensures that there is a "transition" property cell
        prepared for receiving a value.
      * Apply transition phase does nothing.
      * Prepare for data property phase ensures that the existing property cell can
        receive the value.
      * Write value phase writes value directly to the current property cell.
      
      JSObject case:
      * Prepare transition phase prepares the object for receiving a data value (which
        could switch an object to dictionary mode).
      * Apply transition phase migrates object to a transition map. If the map happened
        to be a dictionary mode object's map then an uninitialized entry added to the
        properties dictionary.
      * Prepare for data property phase does nothing.
      * Write value phase just puts value to the properties dictionary.
      
      BUG=chromium:576312
      
      Review-Url: https://codereview.chromium.org/2127583002
      Cr-Commit-Position: refs/heads/master@{#37585}
      3fbb4521
  28. 20 Jun, 2016 1 commit
    • adamk's avatar
      [cleanup] Remove dead code from DeclareLookupSlot and rename it · cbc6adc8
      adamk authored
      Runtime_DeclareLookupSlot is used when generating code for var and function declarations
      originating in an eval. Over time, it's accumulated quite a bit of cruft, which this CL removes:
      
        - With legacy const gone, lookup slots never have any property attributes.
        - There was a bit signaling that the variable was from an eval, but that was redundant since
          DeclareLookupSlot is only used for eval.
        - Some Proxy-related code didn't make sense here.
      
      Its name was also not terribly clear: while "LookupSlot" is used in several places, this
      particular function is only used for declaring variables and functions inside sloppy eval.
      Renamed (and split into two) to make this clear for future archeologists.
      
      Also added various DCHECKs to check the assumptions being made.
      
      Review-Url: https://codereview.chromium.org/2061173002
      Cr-Commit-Position: refs/heads/master@{#37111}
      cbc6adc8
  29. 04 May, 2016 1 commit
  30. 11 Feb, 2016 1 commit
  31. 02 Feb, 2016 1 commit
    • jarin's avatar
      Remove the template magic from types.(h|cc), remove types-inl.h. · ef35f11c
      jarin authored
      This CL removes the Config templatization from the types. It is not
      necessary anymore, after the HeapTypes have been removed.
      
      The CL also changes the type hierarchy - the specific type kinds are
      not inner classes of the Type class and they do not inherit from Type.
      This is partly because it seems impossible to make this work without
      templates. Instead, a new TypeBase class is introduced and all the
      structural (i.e., non-bitset) types inherit from it.
      
      The bitset type still requires the bit-munging hack and some nasty
      reinterpret-casts to pretend bitsets are of type Type*. Additionally,
      there is now the same hack for TypeBase - all pointers to the sub-types
      of TypeBase are reinterpret-casted to Type*. This is to keep the type
      constructors in inline method definitions (although it is unclear how
      much that actually buys us).
      
      In future, we would like to move to a model where we encapsulate Type*
      into a class (or possibly use Type where we used to use Type*). This
      would loosen the coupling between bitset size and pointer size, and
      eventually we would be able to have more bits.
      
      TBR=bradnelson@chromium.org
      
      Review URL: https://codereview.chromium.org/1655833002
      
      Cr-Commit-Position: refs/heads/master@{#33656}
      ef35f11c
  32. 09 Dec, 2015 1 commit
  33. 02 Dec, 2015 1 commit
  34. 12 Oct, 2015 1 commit
    • littledan's avatar
      Test for var declarations in eval which conflict with let · d515e513
      littledan authored
      Previously, name conflicts between var and let declarations were only
      made into exceptions if they were visible at parse-time. This patch adds
      runtime checks so that sloppy-mode direct eval can't introduce conflicting
      var declarations. The change is implemented by traversing the scope chain
      when a direct eval introduces a var declaration to look for conflicting
      let declarations, up to the function boundary.
      
      BUG=v8:4454
      R=adamk
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1382513003
      
      Cr-Commit-Position: refs/heads/master@{#31211}
      d515e513
  35. 30 Sep, 2015 1 commit
  36. 31 Jul, 2015 1 commit