1. 11 Dec, 2017 1 commit
    • Jaroslav Sevcik's avatar
      Reland "[deoptimizer] Staged materialization of objects." · 1da91b83
      Jaroslav Sevcik authored
      This relands commit e71b8022.
      
      This can now back in as the fix for chromium:787301 had enough time to
      be tested in Canary.
      
      Original change's description:
      > [deoptimizer] Staged materialization of objects.
      >
      > The existing object materialization in the deoptimizer has the following problems:
      >
      > - Objects do not necessarily verify during materialization (because during the
      >   depth first walk we might have inconsistent objects).
      >
      > - Stack can overflow (because we just materialize using recursive calls).
      >
      > - We generalize object fields.
      >
      >
      > This CL re-implements the materialization algorithm to solve this problem. The
      > new implementation creates the objects in two steps:
      >
      > 1. We allocate space for all the objects. In general, we allocate ByteArrays
      >    of the right size. For leaf objects that cannot participate in cycles,
      >    we build and initialize the materialized objects completely.
      >
      >    For JS objects, we insert markers into the byte array at the positions
      >    where unboxed doubles are expected.
      >
      > 2. We initialize all the objects with the proper field values and change the
      >    map from the ByteArray map to the correct map. This requires some sync
      >    with the concurrent marker (Heap::NotifyObjectLayoutChange).
      >
      >    When initializing the JS object fields, we make sure that we respect
      >    the unboxed double marker.
      >
      > Bug: chromium:770106, v8:3836
      > Change-Id: I1ec466a9d19db9538df4ba915516d4c3ca825632
      > Reviewed-on: https://chromium-review.googlesource.com/777559
      > Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49821}
      
      Bug: chromium:770106, v8:3836
      Change-Id: Ied6c4e0fbae52713e55ae6dc13794a7521dbb8a5
      Reviewed-on: https://chromium-review.googlesource.com/817745Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49982}
      1da91b83
  2. 18 Oct, 2017 2 commits
    • Jaroslav Sevcik's avatar
      [deoptimizer] Remove incorrect cast for materialized property array. · 57c6c979
      Jaroslav Sevcik authored
      Bug: chromium:774824
      Change-Id: Id3d0af0bb55c0985393fe3b139308b6b706e7bc0
      Reviewed-on: https://chromium-review.googlesource.com/725339Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48665}
      57c6c979
    • Tobias Tebbi's avatar
      Reland^4 "[turbofan] eagerly prune None types and deadness from the graph" · 1cee0e01
      Tobias Tebbi authored
      This fixes https://bugs.chromium.org/p/chromium/issues/detail?id=773954.
      The issue was that in the EffectControlLinearizer, the effect input of an
      {Unreachable} node was not updated, leaving a {Checkpoint} behind.
      
      This is a reland of 4cf47645
      Original change's description:
      > Reland^3 "[turbofan] eagerly prune None types and deadness from the graph"
      > 
      > This fixes the issues 
      > https://bugs.chromium.org/p/chromium/issues/detail?id=772873 
      > and https://bugs.chromium.org/p/chromium/issues/detail?id=772872.
      > 
      > One problem was that mutating an effect node into Unreachable confused 
      > the LoadElimination sidetables, so I just always create a new node now.
      > 
      > The other problem was that UpdateBlockControl() was executed after 
      > UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input.
      > So now I make sure that UpdateEffectPhi() is always executed last.
      > 
      > This is a reland of 6ddb5e7d
      > Original change's description:
      > > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph"
      > > 
      > > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the 
      > > graph end. This fixes issues with later phases running DeadCodeElimination and
      > > introducing new DeadValue nodes when processing uses of Unreachable.
      > > 
      > > This is a reland of 3c4bc27f
      > > Original change's description:
      > > > Reland "[turbofan] eagerly prune None types and deadness from the graph"
      > > > 
      > > > This is a reland of e1cdda25
      > > > Original change's description:
      > > > > [turbofan] eagerly prune None types and deadness from the graph
      > > > > 
      > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that 
      > > > > depend on them, we introduce a {DeadValue} node representing an impossible value 
      > > > > that can occur at any position in the graph. The extended {DeadCodeElimination}
      > > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into
      > > > > the effect chain when possible. The remaining uses of {DeadValue} are handled
      > > > > in {EffectControlLinearizer}, where we always have access to the effect chain.
      > > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use
      > > > > of a node with type {None} as dead.
      > > > > 
      > > > > Bug: chromium:741225
      > > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655
      > > > > Reviewed-on: https://chromium-review.googlesource.com/641250
      > > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > > > Cr-Commit-Position: refs/heads/master@{#48208}
      > > > 
      > > > Bug: chromium:741225
      > > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138
      > > > Reviewed-on: https://chromium-review.googlesource.com/692034
      > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#48232}
      > > 
      > > Bug: chromium:741225
      > > Change-Id: I5702ec34856c075717162153adc765774453c45f
      > > Reviewed-on: https://chromium-review.googlesource.com/702264
      > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#48366}
      > 
      > Bug: chromium:741225
      > Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f
      > Reviewed-on: https://chromium-review.googlesource.com/709214
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48469}
      
      Bug: chromium:741225
      Change-Id: Id9d4f3a3ae36cb3e38f80edcdba88efa7922ca24
      Reviewed-on: https://chromium-review.googlesource.com/715716Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48660}
      1cee0e01
  3. 06 Oct, 2017 1 commit
  4. 09 Jan, 2017 1 commit
  5. 05 Feb, 2016 1 commit
  6. 15 Jan, 2016 1 commit
  7. 24 Jun, 2014 1 commit
  8. 04 Jun, 2014 1 commit
  9. 03 Apr, 2014 1 commit
  10. 31 Mar, 2014 1 commit
  11. 28 Feb, 2014 3 commits
  12. 25 Feb, 2014 1 commit
  13. 20 Feb, 2014 1 commit
  14. 14 Feb, 2014 1 commit