1. 06 Mar, 2019 1 commit
  2. 27 Feb, 2019 1 commit
  3. 26 Feb, 2019 1 commit
  4. 05 Mar, 2018 1 commit
    • Benedikt Meurer's avatar
      [es2015] Refactor the JSArrayIterator. · 06ee127b
      Benedikt Meurer authored
      This changes the JSArrayIterator to always have only a single instance
      type, instead of the zoo of instance types that we had before, and
      which became less useful with the specification update to when "next"
      is loaded from the iterator now. This greatly simplifies the baseline
      implementation of the array iterator, which now only looks at the
      iterated object during %ArrayIteratorPrototype%.next invocations.
      
      In TurboFan we introduce a new JSCreateArrayIterator operator, that
      holds the IterationKind and get's the iterated object as input. When
      optimizing %ArrayIteratorPrototype%.next in the JSCallReducer, we
      check whether the receiver is a JSCreateArrayIterator, and if so,
      we try to infer maps for the iterated object from there. If we find
      any, we speculatively assume that these won't have changed during
      iteration (as we did before with the previous approach), and generate
      fast code for both JSArray and JSTypedArray iteration.
      
      Drive-by-fix: Drop the fast_array_iteration protector, it's not
      necessary anymore since we have the deoptimization guard bit in
      the JSCallReducer now.
      
      This addresses the performance cliff noticed in webpack 4. The minimal
      repro on the tracking bug goes from
      
        console.timeEnd: mono, 124.773000
        console.timeEnd: poly, 670.353000
      
      to
      
        console.timeEnd: mono, 118.709000
        console.timeEnd: poly, 141.393000
      
      so that's a 4.7x improvement.
      
      Also make presubmit happy by adding the missing #undef's.
      
      Bug: v8:7510, v7:7514
      Change-Id: I79a46bfa2cd0f0710e09365ef72519b1bbb667b5
      Reviewed-on: https://chromium-review.googlesource.com/946098Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51725}
      06ee127b
  5. 28 Apr, 2017 1 commit
  6. 26 Jan, 2017 1 commit
  7. 02 Jan, 2017 1 commit
    • bmeurer's avatar
      [crankshaft] Don't bailout on uninitialized access to arguments object. · 380a0207
      bmeurer authored
      When Crankshaft compiles a keyed load to arguments, it disabled
      optimization unless the KEYED_LOAD_IC for the access was monomorphic.
      But that's too restrictive, since it will also disable optimization
      for this function when the access is on a path that was never executed
      so far.
      
      This was spotted in the Node.js core function EventEmitter.prototype.emit,
      which was no longer optimizable with Crankshaft using latest V8.
      
      R=jarin@chromium.org
      BUG=v8:5790
      
      Review-Url: https://codereview.chromium.org/2607303002
      Cr-Commit-Position: refs/heads/master@{#42005}
      380a0207