1. 21 Aug, 2017 1 commit
  2. 14 Aug, 2017 1 commit
  3. 04 Aug, 2017 1 commit
  4. 03 Aug, 2017 1 commit
  5. 02 Aug, 2017 1 commit
    • Yang Guo's avatar
      Support circular references between generated builtins. · 266be35b
      Yang Guo authored
      Until now, when generating a builtin, it can only embed builtins
      (as call targets) that have already been generated. This is either
      achieved by reordering the builtins list, or by loading the call
      target at runtime from the builtins list (see
      MacroAssembler::TailCallBuiltin).
      
      This patch works around this issue by filling the builtins list
      with dummy code objects, which are later replaced with the completed
      actual builtins. In release mode, this adds around 3ms to 140ms we
      previously needed to populate the builtins list. 
      
      Change-Id: I7d451b3c09a1db4b9e755548102a80c7f0dfada2
      Reviewed-on: https://chromium-review.googlesource.com/586531
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47062}
      266be35b
  6. 24 Jul, 2017 1 commit
  7. 19 Jul, 2017 1 commit
  8. 14 Jul, 2017 1 commit
  9. 13 Jul, 2017 1 commit
  10. 10 Jul, 2017 1 commit
    • Jaroslav Sevcik's avatar
      Initial optimization of Map.prototype.(get|has) in Turbofan. · aba708a1
      Jaroslav Sevcik authored
      This introduces a new builtin (MapLookupHashIndex) and uses it
      in Turbofan to compute Map.p.get and Map.p.has.
      
      I have also refactored the existing CSA builtins for Map.p.get and 
      Map.p.has to use the new builtin under the hood.
      
      The code for the lookup has been also improved.
      - Specialized lookups for smis, strings, heap numbers and everything else.
        - the advantage is that we can use fast equalities for the lookup.
        - strings can likely be optimized further if we care about the 
          internalized string fast case.
      - Instead of a call to runtime to get the hash code, we now call C directly.
      
      In the Turbofan implementation itself, there are no special optimizations yet.
      The next step is to teach load elimination to reuse the indexes from
      previous calls of MapLookupHashIndex. 
      
      BUG=v8:6410
      
      Change-Id: I0b1a70493eb031d444e51002f6b2cc1f30ea2b68
      Reviewed-on: https://chromium-review.googlesource.com/560169Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46510}
      aba708a1
  11. 23 Jun, 2017 1 commit
  12. 06 Jun, 2017 1 commit
  13. 02 Jun, 2017 1 commit
  14. 01 Jun, 2017 1 commit
  15. 17 May, 2017 1 commit
  16. 05 May, 2017 1 commit
    • jgruber's avatar
      [string] Move String.p.toLowerCase to CSA · f0e95769
      jgruber authored
      This CL migrates the CPP builtin to CSA with fast paths for strings
      that can be unpacked to direct one-byte strings. Short strings are
      handled directly in CSA, others need to call into C for conversion.
      
      Microbenchmarks for "abcd".toLowerCase() show speedups of 2.5x.
      
      BUG=v8:6353,v8:6344
      
      Review-Url: https://codereview.chromium.org/2859203002
      Cr-Commit-Position: refs/heads/master@{#45141}
      f0e95769
  17. 25 Apr, 2017 1 commit
  18. 19 Apr, 2017 1 commit
    • jgruber's avatar
      [string] Widen StringIndexOf fast path · 4cb01188
      jgruber authored
      The StringIndexOf fast path used to be very narrow, only allowing
      one-byte single-char search strings (and a one-byte subject string).
      
      This changes the CSA fast path to call into our internal SearchString C++
      function instead (after attempting to unpack both Strings), and can handle
      strings of arbitrary length and encoding. The only remaining runtime call is
      when either string needs to be flattened.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2814373002
      Cr-Commit-Position: refs/heads/master@{#44718}
      4cb01188
  19. 13 Apr, 2017 1 commit
  20. 04 Apr, 2017 1 commit
  21. 31 Mar, 2017 2 commits
    • Peter Marshall's avatar
      [builtins] Copy array contents using JS in ConstructByArrayLike. · a450c185
      Peter Marshall authored
      The last CL https://chromium-review.googlesource.com/c/456707/ caused
      some pretty heavy performance regressions. After experimenting, it
      seems the easiest and most straight-forward way to copy the elements
      into the new typed array is to do it in JS.
      
      Adds a fast path for typed arrays, where the source typed array has
      the same elements kind, in which case we can just copy the backing
      store using memcpy.
      
      This CL also removes regression test 319120 which is from a pwn2own
      vulnerability. The old code path enforced a maximum byte_length
      that was too low, which this change removes. The length property of
      the typed array must be a Smi, but the byte_length, which can be up
      to 8x larger than length for a Float64Array, can be a heap number.
      
      We can also re-use some of the logic from ConstructByLength when
      deciding whether to allocate the buffer on- or off-heap, so that
      is factored out into InitializeBasedOnLength. We can also re-use
      the DoInitialize helper instead of calling into the runtime,
      meaning we can remove InitializeFromArrayLike.
      
      BUG=v8:5977,chromium:705503,chromium:705394
      
      Change-Id: I63372652091d4bdf3a9491acef9b4e3ac793a755
      Reviewed-on: https://chromium-review.googlesource.com/459621Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44301}
      a450c185
    • jgruber's avatar
      [regexp] Add support for dotAll flag · cec39ad1
      jgruber authored
      The dotAll flag changes behavior of the dot '.' character to match every
      possible single character instead of excluding certain line terminators.
      
      The implementation is staged behind --harmony-regexp-dotall.
      
      Spec proposal: https://github.com/mathiasbynens/es-regexp-dotall-flag
      
      BUG=v8:6172
      
      Review-Url: https://codereview.chromium.org/2780173002
      Cr-Commit-Position: refs/heads/master@{#44295}
      cec39ad1
  22. 07 Mar, 2017 1 commit
  23. 02 Mar, 2017 1 commit
  24. 01 Mar, 2017 2 commits
    • Peter Marshall's avatar
      Revert "[builtins] Port TypedArrayInitialize to CodeStubAssembler." · a8e15e8f
      Peter Marshall authored
      This reverts commit b23b2c10.
      
      Reason for revert: Makes Linux debug bot sad
      
      Original change's description:
      > [builtins] Port TypedArrayInitialize to CodeStubAssembler.
      > 
      > Turbofan is a lot slower than Crankshaft at constructing TypedArrays,
      > because we always go to the C++ builtin. Port the builtin to CSA
      > to improve performance, and to clean up the implementation, which is
      > split across multiple files and pieces at the moment.
      > 
      > This CL increases the performance with --future to roughly the same
      > as with crankshaft.
      > 
      > BUG=v8:5977
      > 
      > Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8
      > Reviewed-on: https://chromium-review.googlesource.com/445717
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#43518}
      
      TBR=cbruni@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,v8-reviews@googlegroups.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5977
      
      Change-Id: I5d5bc8b4677a405c716d78e688af80ae9c737b4a
      Reviewed-on: https://chromium-review.googlesource.com/448558Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43520}
      a8e15e8f
    • Peter Marshall's avatar
      [builtins] Port TypedArrayInitialize to CodeStubAssembler. · b23b2c10
      Peter Marshall authored
      Turbofan is a lot slower than Crankshaft at constructing TypedArrays,
      because we always go to the C++ builtin. Port the builtin to CSA
      to improve performance, and to clean up the implementation, which is
      split across multiple files and pieces at the moment.
      
      This CL increases the performance with --future to roughly the same
      as with crankshaft.
      
      BUG=v8:5977
      
      Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8
      Reviewed-on: https://chromium-review.googlesource.com/445717
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43518}
      b23b2c10
  25. 23 Feb, 2017 1 commit
  26. 20 Feb, 2017 1 commit
  27. 27 Jan, 2017 1 commit
    • yangguo's avatar
      [liveedit] reimplement frame restarting. · 3f47c63d
      yangguo authored
      Previously, when restarting a frame, we would rewrite all frames
      between the debugger activation and the frame to restart to squash
      them, and replace the return address with that of a builtin to
      leave that rewritten frame, and restart the function by calling it.
      
      We now simply remember the frame to drop to, and upon returning
      from the debugger, we check whether to drop the frame, load the
      new FP, and restart the function.
      
      R=jgruber@chromium.org, mstarzinger@chromium.org
      BUG=v8:5587
      
      Review-Url: https://codereview.chromium.org/2636913002
      Cr-Commit-Position: refs/heads/master@{#42725}
      3f47c63d
  28. 25 Jan, 2017 1 commit
    • kozyatinskiy's avatar
      [inspector] change target promise for kDebugWillHandle & kDebugDidHandle · cb545a8c
      kozyatinskiy authored
      - kDebugPromiseCreated(task, parent_task)
      This event occurs when promise is created (PromiseHookType::Init). V8Debugger uses this event to maintain task -> parent task map.
      
      - kDebugEnqueueAsyncFunction(task)
      This event occurs when first internal promise for async function is created. V8Debugger collects stack trace at this point.
      
      - kDebugEnqueuePromiseResolve(task),
      This event occurs when Promise fulfills with resolved status. V8Debugger collects stack trace at this point.
      
      - kDebugEnqueuePromiseReject(task),
      This event occurs when Promise fulfills with rejected status. V8Debugger collects stack trace at this point.
      
      - kDebugPromiseCollected,
      This event occurs when Promise is collected and no other chained callbacks can be added. V8Debugger removes information about async task for this promise.
      
      - kDebugWillHandle,
      This event occurs when chained promise function (either resolve or reject handler) is called. V8Debugger installs parent promise's stack (based on task -> parent_task map) as current if available or current promise's scheduled stack otherwise.
      
      - kDebugDidHandle,
      This event occurs after chained promise function has finished. V8Debugger restores asynchronous call chain to previous one.
      
      With this change all instrumentation calls are related to current promise (before WillHandle and DidHandle were related to next async task).
      
      Before V8Debugger supported only the following:
      - asyncTaskScheduled(task1)
      - asyncTaskStarted(task1)
      - asyncTaskFinished(task1)
      
      Now V8Debugger supports the following:
      - asyncTaskScheduled(parent_task)
      ..
      - asyncTaskCreated(task, parent_task),
      - asyncTaskStarted(task), uses parent_task scheduled stack
      - asyncTaskScheduled(task)
      - asyncTaskFinished(task)
      
      Additionally: WillHandle and DidHandle were migrated to PromiseHook API.
      
      More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE
      
      BUG=v8:5738
      R=dgozman@chromium.org,gsathya@chromium.org,yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2650803003
      Cr-Commit-Position: refs/heads/master@{#42644}
      cb545a8c
  29. 12 Jan, 2017 1 commit
  30. 16 Dec, 2016 2 commits
  31. 15 Dec, 2016 1 commit
    • ahaas's avatar
      [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code. · 7bd61b60
      ahaas authored
      Some instructions in WebAssembly trap for some inputs, which means that the
      execution is terminated and (at least at the moment) a JavaScript exception is
      thrown. Examples for traps are out-of-bounds memory accesses, or integer
      divisions by zero.
      
      Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
      TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
      constant), in addition to the trap condition itself. Additionally, each
      WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
      number of inputs is linear to the number of trap checks in the function.
      Especially for functions with high numbers of trap checks we observe a
      significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
      benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
      a TrapIf common operator only a single node is necessary per trap check, in
      addition to the trap condition. Also the nodes which are shared between trap
      checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
      speedup of 30-50% on average.
      
      This CL only implements TrapIf and TrapUnless on x64. The implementation is also
      hidden behind the --wasm-trap-if flag.
      
      Please take a special look at how the source position is transfered from the
      instruction selector to the code generator, and at the context that is used for
      the runtime call.
      
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2562393002
      Cr-Commit-Position: refs/heads/master@{#41720}
      7bd61b60
  32. 09 Dec, 2016 1 commit
    • gsathya's avatar
      [promisehook] Add is_promisehook_enabled · d778b36f
      gsathya authored
      This will be used in CSA to check if any promisehook is set.
      
      -- Adds a is_promisehook_enabled_ field to the isolate and helper methods.
      -- Adds this field to the ExternalReference table.
      -- Adds a helper method to access this from CSA
      
      Note -- this patch doesn't actually add the ability to attach the hook
      yet.
      
      BUG=v8:4643
      
      Review-Url: https://codereview.chromium.org/2566483002
      Cr-Commit-Position: refs/heads/master@{#41607}
      d778b36f
  33. 08 Dec, 2016 1 commit
  34. 15 Nov, 2016 3 commits
  35. 14 Nov, 2016 1 commit
    • yangguo's avatar
      [serializer] small fixes for blink snapshot. · c759a3d8
      yangguo authored
      Changes include:
       - Adding V8_EXPORT macro for SnapshotCreator
       - Removing outdated DCHECKs.
       - Allow nullptr as external reference. This required a...
       - Refactoring of hashmaps used by the serializer.
       - Remove external references for counters. These are not used
         anywhere for isolates that are being serialized.
       - Put template infos into the partial snapshot cache.
       - Remove unnecessary presubmit check for external references.
         mksnapshot crashes if external references are missing.
      
      R=jochen@chromium.org, vogelheim@chromium.org
      BUG=chromium:617892
      
      Review-Url: https://codereview.chromium.org/2490783004
      Cr-Commit-Position: refs/heads/master@{#40949}
      c759a3d8