1. 19 Dec, 2018 1 commit
  2. 17 Dec, 2018 1 commit
  3. 07 Dec, 2018 1 commit
  4. 21 Nov, 2018 1 commit
  5. 29 Oct, 2018 1 commit
  6. 22 Oct, 2018 1 commit
  7. 18 Oct, 2018 2 commits
  8. 15 Oct, 2018 1 commit
  9. 11 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Introduce dedicated JSAsyncFunctionObject. · a63987a4
      Benedikt Meurer authored
      This JSAsyncFunctionObject represents the implicit generator object
      inside of async functions, and also holds the outer promise for the
      async functions. This in turn allows us to get rid of the .promise
      in the Parser / BytecodeGenerator completely, and will make it
      possible to build zero-cost async stack traces independent of the
      concrete synchronous part of the stack frame (which currently breaks
      in Node.js).
      
      In the bytecode all the async function operations now take this new
      JSAsyncFunctionObject instead of passing both the .generator_object
      and the .promise, which further simplifies and shrinks the bytecode.
      It also reduces the size of async function frames, potentially making
      the suspend/resume cheaper.
      
      This also changes `await` to use intrinsics instead of calling to
      special JSFunctions on the native context, and thus reduces the size of
      the native contexts.
      
      Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator
      to TurboFan.
      
      Bug: v8:7253, v8:7522
      Change-Id: I2305302285156aa1f71328ecac70377abdd92c80
      Ref: nodejs/node#11865
      Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
      Reviewed-on: https://chromium-review.googlesource.com/c/1273049
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56554}
      a63987a4
  10. 08 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Escape analysis support for LoadElement with variable index. · 3e43ded9
      Benedikt Meurer authored
      This adds support to the escape analysis to allow scalar replacement
      of (small) FixedArrays with element accesses where the index is not a
      compile time constant. This happens quite often when inlining functions
      that operate on variable number of arguments. For example consider this
      little piece of code:
      
      ```js
      function sum(...args) {
        let s = 0;
        for (let i = 0; i < args.length; ++i) s += args[i];
        return s;
      }
      
      function sum2(x, y) {
        return sum(x, y);
      }
      ```
      
      This example is made up, of course, but it shows the problem. Let's
      assume that TurboFan inlines the function `sum` into it's call site
      at `sum2`. Now it has to materialize the `args` array with the two
      values `x` and `y`, and iterate through these `args` to sum them up.
      The escape analysis pass figures out that `args` doesn't escape (aka
      doesn't outlive) the optimized code for `sum2` now, but TurboFan still
      needs to materialize the elements backing store for `args` since there's
      a `LoadElement(args.elements,i)` in the graph now, and `i` is not a
      compile time constant.
      
      However the escape analysis has more information than just that. In
      particular the escape analysis knows exactly how many elements a non
      escaping object has, based on the fact that the allocation must be
      local to the function and that we only track objects with known size.
      So in the case above when we get to `args[i]` in the escape analysis
      the relevant part of the graph looks something like this:
      
      ```
      elements = LoadField[elements](args)
      length = LoadField[length](args)
      index = CheckBounds(i, length)
      value = LoadElement(elements, index)
      ```
      
      In particular the contract here is that `LoadElement(elements,index)`
      is guaranteed to have an `index` that is within the valid bounds for
      the `elements` (there must be a preceeding `CheckBounds` or some other
      guard in optimized code before it). And since `elements` is allocated
      inside of the optimized code object, the escape analysis also knows
      that `elements` has exactly two elements inside (namely the values of
      `x` and `y`). So we can use that information and replace the access
      with a `Select(index===0,x,y)` operation instead, which allows us to
      scalar replace the `elements`, since there's no escaping use anymore
      in the graph.
      
      We do this for the case that the number of elements is 2, as described
      above, but also for the case where elements length is one. In case
      of 0, we know that the `LoadElement` must be in dead code, but we can't
      just mark it for deletion from the graph (to make sure it doesn't block
      scalar replacement of non-dead code), so we don't handle this for now.
      And for one element it's even easier, since the `LoadElement` has to
      yield exactly said element.
      
      We could generalize this to handle arbitrary lengths, but since there's
      a cost to arbitrary decision trees here, it's unclear when this is still
      beneficial. Another possible solution for length > 2 would be to have
      special stack allocation for these backing stores and do variable index
      accesses to these stack areas. But that's way beyond the scope of this
      isolated change.
      
      This change shows a ~2% improvement on the EarleyBoyer benchmark in
      JetStream, since it benefits a lot from not having to materialize these
      small arguments backing stores.
      
      Drive-by-fix: Fix JSCreateLowering to properly initialize "elements"
      with StoreElement instead of StoreField (which violates the invariant
      in TurboFan that fields and elements never alias).
      
      Bug: v8:5267, v8:6200
      Change-Id: Idd464a15a81e7c9653c48c814b406eb859841428
      Reviewed-on: https://chromium-review.googlesource.com/c/1267935
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56442}
      3e43ded9
  11. 01 Oct, 2018 2 commits
  12. 26 Sep, 2018 1 commit
  13. 19 Sep, 2018 1 commit
  14. 18 Sep, 2018 2 commits
    • Georg Neis's avatar
      [turbofan] Get rid of HeapObjectType-related heap reads. · 253c2469
      Georg Neis authored
      This removes the last unconditional read accesses to the heap, but
      required a significant refactoring.
      
      - Remove HeapObjectRef::type().
      - Change HeapObjectData::Is* testers to look at the instance type
        in HeapObjectData::map().
      
      - Remove ObjectRef::oddball_type()
      - Add MapRef::oddball_type()
      - Add MapRef::is_undetectable().
      - Add MapRef::is_callable().
      
      - Remove JSHeapBroker::HeapObjectTypeFromMap()
      - Remove Type::For(JSHeapBroker*, Handle<Map>)
      - Add BitsetType::Lub(MapRef).
      - Add Type::For(MapRef).
      - Add Type::For(HeapObjectType).
      
      - Add HeapObjectRef::GetHeapObjectType(). THIS IS TEMPORARY.
      
      As the last item suggests, I couldn't actually remove the
      HeapObjectType class yet. See the explanation in the code.
      
      Bug: v8:7790
      Change-Id: I508e4bd5337277b0050f2204392fc36f41032fe9
      Reviewed-on: https://chromium-review.googlesource.com/1228033Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55994}
      253c2469
    • Georg Neis's avatar
      [turbofan] Serialize IsUnboxedDoubleField. · 043dfe76
      Georg Neis authored
      I'm also changing the function signature to take the descriptor_index
      instead of the FieldIndex, because this lets me reuse the vector of
      property descriptors as storage.
      
      Bug: v8:7790
      Change-Id: Ie9dadcba2204b6825e5791f9c630fc8b1079a930
      Reviewed-on: https://chromium-review.googlesource.com/1227873
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55981}
      043dfe76
  15. 17 Sep, 2018 1 commit
  16. 13 Sep, 2018 1 commit
  17. 29 Aug, 2018 1 commit
  18. 22 Aug, 2018 1 commit
  19. 20 Aug, 2018 1 commit
  20. 17 Aug, 2018 3 commits
  21. 16 Aug, 2018 2 commits
  22. 14 Aug, 2018 1 commit
  23. 08 Aug, 2018 1 commit
    • Jaroslav Sevcik's avatar
      [turbofan] Optimistic slack tracking completion. · bba36e19
      Jaroslav Sevcik authored
      The idea is to compute the slack before compilation start. Then
      we check that the slack tracking decision is the same at the end
      of compilation. If it is, we just commit to that slack tracking
      (by calling function->CompleteInobjectSlackTrackingIfActive).
      If the slack tracking decision changed, we will retry the compilation.
      
      This has several pieces:
      - Expose computation of slack and instance size from the object model.
      - Add compilation dependency on the slack tracking result.
      - Change create lowering to use the dependency.
      - Fix array creation to use the slack tracking result's instance
        size.
      
      Bug: v8:7790
      Change-Id: Id975300cfd6c1786733cd7cbf55cc507c05738b2
      Reviewed-on: https://chromium-review.googlesource.com/1164957Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54982}
      bba36e19
  24. 07 Aug, 2018 1 commit
  25. 02 Aug, 2018 1 commit
  26. 01 Aug, 2018 1 commit
  27. 20 Jul, 2018 2 commits
  28. 19 Jul, 2018 2 commits
  29. 18 Jul, 2018 3 commits
  30. 17 Jul, 2018 1 commit