1. 12 Aug, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Fix multiple races in Map::FindElementsKindTransitionedMap · 1b22e6fb
      Jakob Gruber authored
      The concurrent version was added recently in crrev.com/c/3085262.
      
      - UnusedPropertyFields requires the MapUpdater lock.
      - instance_descriptors must be read atomically on the bg thread.
      
      Finally, there appears to be a false positive report for the pattern:
      
       x = is_concurrent ? foo(kAcquireLoad) : foo();
      
      Here, clang emits code that executes both the atomic and nonatomic
      reads when is_concurrent is true. Needs more investigation.
      
      Bug: v8:7790, chromium:1239009
      Change-Id: I07d442e72cf0278f79f202a267e8d246f8abca1b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3090341
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76261}
      1b22e6fb
  2. 11 Aug, 2021 1 commit
  3. 17 May, 2021 1 commit
  4. 03 May, 2021 1 commit
  5. 08 Apr, 2021 1 commit
  6. 06 Apr, 2021 1 commit
  7. 01 Apr, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Add the MapUpdater lock · 605f9875
      Jakob Gruber authored
      It's locked exclusively in the MapUpdater API methods, and locked
      shared in ComputePropertyAccessInfo (CPAI).
      
      This lock is a step towards running CPAI on background threads. The
      simple lock portion is landed separately in this CL to get an early
      signal on potential lock overhead perf impact.
      
      The lock is implemented and used very conservatively at the moment:
      
      - it's a single global lock (and not e.g. per-map).
      - it's locked for the entire method call duration (instead of only in
        relevant parts).
      
      Both points can potentially be improved in the future.
      
      Bug: v8:7790
      Change-Id: I073423497e01b4901101973387a19962f953a576
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2797286Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73773}
      605f9875
  8. 08 Mar, 2021 2 commits
  9. 05 Mar, 2021 1 commit
  10. 23 Feb, 2021 1 commit
  11. 11 Feb, 2021 1 commit
  12. 20 Nov, 2020 1 commit
  13. 12 Nov, 2020 1 commit
  14. 30 Oct, 2020 1 commit
  15. 29 Oct, 2020 1 commit
  16. 05 Oct, 2020 1 commit
  17. 19 Jun, 2020 1 commit
  18. 11 Oct, 2019 1 commit
  19. 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
  20. 19 Jun, 2019 1 commit
  21. 28 May, 2019 1 commit
  22. 27 May, 2019 3 commits
    • Benedikt Meurer's avatar
      Reland "[typedarray] Move external/data pointer to JSTypedArray." · 70bd7cf0
      Benedikt Meurer authored
      This is a reland of 4b86fea5 with
      copy&paste typo in CodeStubAssembler::AllocateByteArray() fixed
      (bug led to holes in new space, which was crashing reproducibly
      on the ia32 bot).
      
      Original change's description:
      > [typedarray] Move external/data pointer to JSTypedArray.
      >
      > As the next step in supporting huge typed arrays in V8, this moves the
      > external/data pointer from the FixedTypedArrayBase backing store to the
      > JSTypedArray instance itself, and replaces the special backing stores
      > with a plain ByteArray (removing all the code for the FixedTypedArrayBase
      > class hierarchy). By doing so, we can drastically simplify the system
      > around typed arrays.
      >
      > Note: Several places in the code base used to check the instance type
      > of the elements backing store of a JSTypedArray instead of checking the
      > elements kind on the JSTypedArray map directly. Those had to be fixed,
      > since the backing store is now always a ByteArray.
      >
      > Drive-by-fix: Move all the typed elements access related code into the
      > elements.cc file to properly encapsulate the accesses.
      >
      > Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
      > Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      > Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
      > Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61855}
      
      Tbr: petermarshall@chromium.org
      Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      Change-Id: I87fcdb28532c5f08cc227332a4d59546cb423810
      Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_shared_compile_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631592Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61864}
      70bd7cf0
    • Clemens Hammacher's avatar
      Revert "[typedarray] Move external/data pointer to JSTypedArray." · e4db146a
      Clemens Hammacher authored
      This reverts commit 4b86fea5.
      
      Reason for revert: Fails on linux shared: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/31045
      
      Original change's description:
      > [typedarray] Move external/data pointer to JSTypedArray.
      > 
      > As the next step in supporting huge typed arrays in V8, this moves the
      > external/data pointer from the FixedTypedArrayBase backing store to the
      > JSTypedArray instance itself, and replaces the special backing stores
      > with a plain ByteArray (removing all the code for the FixedTypedArrayBase
      > class hierarchy). By doing so, we can drastically simplify the system
      > around typed arrays.
      > 
      > Note: Several places in the code base used to check the instance type
      > of the elements backing store of a JSTypedArray instead of checking the
      > elements kind on the JSTypedArray map directly. Those had to be fixed,
      > since the backing store is now always a ByteArray.
      > 
      > Drive-by-fix: Move all the typed elements access related code into the
      > elements.cc file to properly encapsulate the accesses.
      > 
      > Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
      > Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      > Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
      > Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61855}
      
      TBR=ulan@chromium.org,yangguo@chromium.org,titzer@chromium.org,sigurds@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,szuend@chromium.org
      
      Change-Id: I0bc1f935de6063acf75a0f4bb8c0ba67428603fd
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631427Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61856}
      e4db146a
    • Benedikt Meurer's avatar
      [typedarray] Move external/data pointer to JSTypedArray. · 4b86fea5
      Benedikt Meurer authored
      As the next step in supporting huge typed arrays in V8, this moves the
      external/data pointer from the FixedTypedArrayBase backing store to the
      JSTypedArray instance itself, and replaces the special backing stores
      with a plain ByteArray (removing all the code for the FixedTypedArrayBase
      class hierarchy). By doing so, we can drastically simplify the system
      around typed arrays.
      
      Note: Several places in the code base used to check the instance type
      of the elements backing store of a JSTypedArray instead of checking the
      elements kind on the JSTypedArray map directly. Those had to be fixed,
      since the backing store is now always a ByteArray.
      
      Drive-by-fix: Move all the typed elements access related code into the
      elements.cc file to properly encapsulate the accesses.
      
      Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
      Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
      Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61855}
      4b86fea5
  23. 23 May, 2019 3 commits
  24. 22 May, 2019 1 commit
  25. 21 May, 2019 1 commit
  26. 20 May, 2019 2 commits
  27. 07 May, 2019 2 commits
  28. 27 Apr, 2019 1 commit
  29. 16 Apr, 2019 1 commit
  30. 12 Apr, 2019 4 commits
    • Sathya Gunasekaran's avatar
      Revert "Fix array.concat with double for sealed, frozen object" · 40004881
      Sathya Gunasekaran authored
      This reverts commit 68ba8574.
      
      Reason for revert: breaks windows builds https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20builder/27839
      
      Original change's description:
      > Fix array.concat with double for sealed, frozen object
      > 
      > Treat packed sealed, frozen element as packed element.
      > Also rename to IsPackedFrozenOrSealedElementsKind.
      > 
      > Bug: chromium:951988
      > Change-Id: Ia636f0a14a229e4c44772627728927db1b877f27
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565470
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#60831}
      
      TBR=jarin@chromium.org,ishell@chromium.org,verwaest@chromium.org,duongn@microsoft.com
      
      Change-Id: I84caf106dbdd2209aef0a994173e1c3982e9f7b1
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:951988
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565542Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60832}
      40004881
    • Z Duong Nguyen-Huu's avatar
      Fix array.concat with double for sealed, frozen object · 68ba8574
      Z Duong Nguyen-Huu authored
      Treat packed sealed, frozen element as packed element.
      Also rename to IsPackedFrozenOrSealedElementsKind.
      
      Bug: chromium:951988
      Change-Id: Ia636f0a14a229e4c44772627728927db1b877f27
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565470Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#60831}
      68ba8574
    • 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