1. 21 May, 2019 2 commits
  2. 20 May, 2019 1 commit
  3. 17 May, 2019 2 commits
  4. 14 May, 2019 1 commit
  5. 06 May, 2019 1 commit
  6. 29 Apr, 2019 1 commit
    • Benedikt Meurer's avatar
      [runtime] Optimize general object spread. · 4995c85f
      Benedikt Meurer authored
      This adds a new %_CopyDataProperties intrinsic, that reuses most of the
      existing machinery that we already have in place for Object.assign() and
      computed property names in object literals. This speeds up the general
      case for object spread (where the spread is not the first item in an
      object literal) and brings it on par with Object.assign() at least - in
      most cases it's significantly faster than Object.assign().
      
      In the test case [1] referenced from the bug, the performance goes from
      
        objectSpreadLast: 3624 ms.
        objectAssignLast: 1938 ms.
      
      to
      
        objectSpreadLast: 646 ms.
        objectAssignLast: 1944 ms.
      
      which corresponds to a **5-6x performance boost**, making object spread
      faster than Object.assign() in general.
      
      Drive-by-fix: This refactors the Object.assign() fast-path in a way that
      it can be reused appropriately for object spread, and adds another new
      builtin SetDataProperties, which does the core of the Object.assign()
      work. We can teach TurboFan to inline Object.assign() based on the new
      SetDataProperties builtin at some later point to further optimize
      Object.assign().
      
      [1]: https://gist.github.com/bmeurer/0dae4a6b0e23f43d5a22d7c91476b6c0
      
      Bug: v8:9167
      Change-Id: I57bea7a8781c4a1e8ff3d394873c3cd4c5d73834
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587376Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61100}
      4995c85f
  7. 24 Apr, 2019 1 commit
    • Jakob Gruber's avatar
      [coverage] Reduce IncBlockCounter overhead · ae6a47ba
      Jakob Gruber authored
      When collecting JS block coverage, we track block execution counts on
      so-called CoverageInfo objects. Generated bytecode and native code
      contains inlined snippets of code to increment the appropriate
      counters.
      
      These used to be implemented as calls to the IncBlockCounter runtime
      function. Each call incurred the entire CEntry overhead.
      
      This CL reduces that overhead by moving logic over into a new
      IncBlockCounter TFS builtin. The builtin is called directly from
      bytecode, and lowered to the same builtin call for optimized code.
      
      Drive-by: Tweak CoverageInfo layout to generate faster code.
      
      Tbr: jarin@chromium.org
      Bug: v8:9149, v8:6000
      Change-Id: I2d7cb0db649edf7c56b5ef5a4683d27b1c34605c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571420Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60981}
      ae6a47ba
  8. 23 Apr, 2019 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. 10 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Improve async function handling. · 0038e5f0
      Benedikt Meurer authored
      This change introduces new intrinsics used to desugar async functions
      in the Parser and the BytecodeGenerator, namely we introduce a new
      %_AsyncFunctionEnter intrinsic that constructs the generator object
      for the async function (and in the future will also create the outer
      promise for the async function). This generator object is internal
      and never escapes to user code, plus since async functions don't have
      a "prototype" property, we can just a single map here instead of tracking
      the prototype/initial_map on every async function. This saves one word
      per async function plus one initial_map per async function that was
      invoked at least once.
      
      We also introduce two new intrinsics %_AsyncFunctionReject, which
      rejects the outer promise with the caught exception, and another
      %_AsyncFunctionResolve, which resolves the outer promise with the
      right hand side of the `return` statement. These functions also perform
      the DevTools part of the job (aka popping from the promise stack and
      sending the debug event). This allows us to get rid of the implicit
      try-finally from async functions completely; because the finally
      block only called to the %AsyncFunctionPromiseRelease builtin, which
      was used to inform DevTools.
      
      In essence we now turn an async function like
      
      ```js
      async function f(x) { return await bar(x); }
      ```
      
      into something like this (in Parser and BytecodeGenerator respectively):
      
      ```
      function f(x) {
        .generator_object = %_AsyncFunctionEnter(.closure, this);
        .promise = %AsyncFunctionCreatePromise();
        try {
          .tmp = await bar(x);
          return %_AsyncFunctionResolve(.promise, .tmp);
        } catch (e) {
          return %_AsyncFunctionReject(.promise, e);
        }
      }
      ```
      
      Overall the bytecode for async functions gets significantly shorter
      already (and will get even shorter once we put the outer promise into
      the async function generator object). For example the bytecode for a
      simple async function
      
      ```js
      async function f(x) { return await x; }
      ```
      
      goes from 175 bytes to 110 bytes (a ~38% reduction in size), which
      is in particular due to the simplification around the try-finally
      removal.
      
      Overall this seems to improve the doxbee-async-es2017-native test by
      around 2-3%. On the test case mentioned in v8:8276 we go from
      1124ms to 441ms, which corresponds to a 60% reduction in total
      execution time!
      
      Tbr: marja@chromium.org
      Bug: v8:7253, v8:7522, v8:8276
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4
      Reviewed-on: https://chromium-review.googlesource.com/c/1269041
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56502}
      0038e5f0
  11. 21 Sep, 2018 1 commit
  12. 20 Sep, 2018 2 commits
  13. 21 Aug, 2018 1 commit
  14. 20 Jul, 2018 1 commit
  15. 18 Jun, 2018 1 commit
    • Clemens Hammacher's avatar
      Make CallInterfaceDescriptor isolate-independent · 3cb376dc
      Clemens Hammacher authored
      Currently each isolate stores its own array of
      {CallInterfaceDescriptorData}. This array has size 173, and each entry
      has 40 bytes. That's already 7kB per isolate.
      Additionally, each {CallInterfaceDescriptorData} allocates two
      heap-allocated arrays, which probably add up to more than the static
      size of the {CallInterfaceDescriptorData}. Note that all the
      {CallInterfaceDescriptorData} instances are initialized eagerly on
      isolate creation.
      
      Since {CallInterfaceDescriptor} is totally isolate independent itself,
      this CL refactors the current design to avoid a copy of them per
      isolate, and instead shares them process-wide. Still, we need to free
      the allocated heap arrays when the last isolate dies to avoid leaks.
      This can probably be refactored later by statically initializing more
      and avoiding the heap allocations all together.
      
      This refactoring will also allow us to use {CallInterfaceDescriptor}s
      from wasm background compilation threads, which are not bound to any
      isolate.
      
      R=mstarzinger@chromium.org, titzer@chromium.org
      
      Bug: v8:6600
      Change-Id: If8625b89951eec8fa8986b49a5c166e874a72494
      Reviewed-on: https://chromium-review.googlesource.com/1100879
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53803}
      3cb376dc
  16. 03 Jun, 2018 1 commit
  17. 14 May, 2018 1 commit
  18. 20 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [async-await] Turn await closures into intrinsics. · d97bb317
      Benedikt Meurer authored
      There's no need to have the AsyncFunctionAwait/AsyncGeneratorAwait
      operations as separate closures that are called via JavaScript calling
      convention, but instead we can just have them as intrinsics (with the
      goal to eventually turn them into IC stubs).
      
      Drive-by-fix: Tail call to the ResumeGenerator builtin when resuming
      an async function. The earlier restrictions no only apply with the new
      machinery.
      
      Bug: v8:7253
      Change-Id: I0c4d04dae15b4211158fc07151adafda69d4faec
      Reviewed-on: https://chromium-review.googlesource.com/924703Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51382}
      d97bb317
  19. 15 Feb, 2018 1 commit
  20. 13 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Refactor the promise resolution and rejection logic. · c0412961
      Benedikt Meurer authored
      This introduces dedicated builtins
      
        - FulfillPromise,
        - RejectPromise, and
        - ResolvePromise,
      
      which perform the corresponding operations from the language
      specification, and removes the redundant entry points and the
      excessive inlining of these operations into other builtins. We
      also add the same logic on the C++ side, so that we don't need
      to go into JavaScript land when resolving/rejecting from the
      API.
      
      The C++ side has a complete implementation, including full support
      for the debugger and the current PromiseHook machinery. This is to
      avoid constantly crossing the boundary for those cases, and to also
      simplify the CSA side (and soon the TurboFan side), where we only
      do the fast-path and bail out to the runtime for the general handling.
      
      On top of this we introduce %_RejectPromise and %_ResolvePromise,
      which are entry points used by the bytecode and parser desugarings
      for async functions, and also used by the V8 Extras API. Thanks to
      this we can uniformly optimize these in TurboFan, where we have
      corresponding operators JSRejectPromise and JSResolvePromise, which
      currently just call into the builtins, but middle-term can be further
      optimized, i.e. to skip the "then" lookup for JSResolvePromise when
      we know something about the resolution.
      
      In TurboFan we can also already inline the default PromiseCapability
      [[Reject]] and [[Resolve]] functions, although this is not as effective
      as it can be right now, until we have inlining support for the Promise
      constructor (being worked on by petermarshall@ right now) and/or SFI
      based CALL_IC feedback.
      
      Overall this change is meant as a refactoring without significant
      performance impact anywhere; it seems to improve performance of
      simple async functions a bit, but otherwise is neutral.
      
      Bug: v8:7253
      Change-Id: Id0b979f9b2843560e38cd8df4b02627dad4b6d8c
      Reviewed-on: https://chromium-review.googlesource.com/911632Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51260}
      c0412961
  21. 09 Feb, 2018 1 commit
  22. 07 Feb, 2018 1 commit
  23. 24 Jan, 2018 1 commit
  24. 19 Jan, 2018 1 commit
  25. 18 Jan, 2018 2 commits
  26. 09 Jan, 2018 1 commit
  27. 11 Dec, 2017 1 commit
  28. 10 Nov, 2017 1 commit
  29. 20 Oct, 2017 1 commit
  30. 18 Oct, 2017 2 commits
  31. 15 Sep, 2017 1 commit
  32. 10 Aug, 2017 1 commit
  33. 08 Aug, 2017 1 commit
  34. 31 Jul, 2017 1 commit
  35. 25 Jul, 2017 1 commit