1. 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
  2. 18 Jun, 2018 2 commits
  3. 15 Jun, 2018 1 commit
  4. 22 Jan, 2018 1 commit
  5. 11 Jan, 2018 1 commit
    • Caitlin Potter's avatar
      Reland "[esnext] load `iterator.next` only once at beginning of iteration" · 2d889aa9
      Caitlin Potter authored
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
      september 2017 TC39 meetings. This moves the load of the "next" method
      to the very beginning of the iteration protocol, rather than during
      each iteration step.
      
      This impacts:
      
      - yield*
      - for-of loops
      - spread arguments
      - array spreads
      
      In the v8 implementation, this also affects async iteration versions of
      these things (the sole exception being the Async-From-Sync iterator,
      which requires a few more changes to work with this, likely done in a
      followup patch).
      
      This change introduces a new AST node, ResolvedProperty, which can be used
      as a callee by Call nodes to produce the same bytecode as Property calls,
      without observably re-loading the property. This is used in several
      AST-desugarings involving the iteration protocol.
      
      BUG=v8:6861, v8:5699
      R=rmcilroy@chromium.org
      TBR=neis@chromium.org, adamk@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b
      Reviewed-on: https://chromium-review.googlesource.com/857593
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50518}
      2d889aa9
  6. 09 Jan, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[esnext] load `iterator.next` only once at beginning of iteration" · 163b5d70
      Michael Achenbach authored
      This reverts commit bf4cc9ee.
      
      Reason for revert: Breaks windows with msvc and linux with gcc
      https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265
      
      Original change's description:
      > [esnext] load `iterator.next` only once at beginning of iteration
      > 
      > https://github.com/tc39/ecma262/pull/988 gained concensus during the
      > september 2017 TC39 meetings. This moves the load of the "next" method
      > to the very beginning of the iteration protocol, rather than during
      > each iteration step.
      > 
      > This impacts:
      > 
      > - yield*
      > - for-of loops
      > - spread arguments
      > - array spreads
      > 
      > In the v8 implementation, this also affects async iteration versions of
      > these things (the sole exception being the Async-From-Sync iterator,
      > which requires a few more changes to work with this, likely done in a
      > followup patch).
      > 
      > This change introduces a new AST node, ResolvedProperty, which can be used
      > as a callee by Call nodes to produce the same bytecode as Property calls,
      > without observably re-loading the property. This is used in several
      > AST-desugarings involving the iteration protocol.
      > 
      > BUG=v8:6861, v8:5699
      > R=​rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
      > Reviewed-on: https://chromium-review.googlesource.com/687997
      > Commit-Queue: Caitlin Potter <caitp@igalia.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50452}
      
      TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org
      
      Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6861, v8:5699
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/857616Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50454}
      163b5d70
    • Caitlin Potter's avatar
      [esnext] load `iterator.next` only once at beginning of iteration · bf4cc9ee
      Caitlin Potter authored
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
      september 2017 TC39 meetings. This moves the load of the "next" method
      to the very beginning of the iteration protocol, rather than during
      each iteration step.
      
      This impacts:
      
      - yield*
      - for-of loops
      - spread arguments
      - array spreads
      
      In the v8 implementation, this also affects async iteration versions of
      these things (the sole exception being the Async-From-Sync iterator,
      which requires a few more changes to work with this, likely done in a
      followup patch).
      
      This change introduces a new AST node, ResolvedProperty, which can be used
      as a callee by Call nodes to produce the same bytecode as Property calls,
      without observably re-loading the property. This is used in several
      AST-desugarings involving the iteration protocol.
      
      BUG=v8:6861, v8:5699
      R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
      Reviewed-on: https://chromium-review.googlesource.com/687997
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50452}
      bf4cc9ee
  7. 06 Dec, 2017 1 commit
  8. 18 Jul, 2017 1 commit
  9. 14 Jul, 2017 2 commits
    • Alexey Kozyatinskiy's avatar
      [inspector] improve return position of explicit return in non-async function · 08965860
      Alexey Kozyatinskiy authored
      Goal of this CL: explicit return from non-async function has position after
      return expression as return position (will unblock [1]).
      
      BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods.
      If one of these methods is called then next generated bytecode will get passed
      position. It's general treatment for most cases.
      Unfortunately it doesn't work for Returns:
      - debugger requires source positions exactly on kReturn bytecode in stepping
        implementation,
      - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn
        generates more then one bytecode and general solution will put return position
        on first generated bytecode,
      - it's not easy to split BuildReturn function into two parts to allow something
        like following in BytecodeGenerator::VisitReturnStatement since generated
        bytecodes are actually controlled by execution_control().
      ..->BuildReturnPrologue();
      ..->SetReturnPosition(stmt);
      ..->Return();
      
      In this CL we pass ReturnStatement through ExecutionControl and use it for
      position when we emit return bytecode right here.
      
      So this CL only will improve return position for returns inside of non-async
      functions, I'll address async functions later.
      
      [1] https://chromium-review.googlesource.com/c/543161/
      
      Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db
      Reviewed-on: https://chromium-review.googlesource.com/560738
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46687}
      08965860
    • Caitlin Potter's avatar
      [async-await] desugar Await in BytecodeGenerator · 8b5b444a
      Caitlin Potter authored
      This includes several changes. From most to least interesting:
      
      - No longer implement AwaitExpressions using a do-expression.
      - Reduces frame-size of async generators by not allocating temporary
        variables to hold results of Await epxressions.
      - Streamline and reduce generated bytecodes for Await.
      - Debugger no longer emits a debug::kCallBreakLocation breakpoint for
      the JS-builtin call performed for Await, and instead only emits such
      a breakpoint if the operand of Await is actually a call.
      - Push fewer parameters to Await* builtins, using the receiver for the
        first parameter (possible now that the CallRuntime invocation not
        part of the AST).
      - Adds a new Await AST node. No new members or anything, but it seemed
        palatable to avoid having `if (is_await())` in a number of
        VisitSuspend functions.
      
      BUG=v8:5855, v8:5099, v8:4483
      R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org
      TBR=bmeurer@chromium.org
      
      Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf
      Reviewed-on: https://chromium-review.googlesource.com/558806
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46666}
      8b5b444a
  10. 07 Jun, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] fixed getPossibleBreakpoints · 9fef8fd2
      Alexey Kozyatinskiy authored
      BytecodeArrayBreakIterator doesn't iterate through locations in position() order. SkipToPosition is looking for closest break_index to passed one. So we should iterate through all breakable locations in function to get all of them.
      
      R=jgruber@chromium.org
      
      Bug: v8:6469
      Change-Id: Ida0b849e9df40458a13e0a0f7af6a00349088228
      Reviewed-on: https://chromium-review.googlesource.com/527135Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45765}
      9fef8fd2
  11. 31 May, 2017 1 commit
  12. 30 May, 2017 1 commit
    • Aleksey Kozyatinskiy's avatar
      [inspector] moved var initialization break location before init expression (reland) · fb6a094d
      Aleksey Kozyatinskiy authored
      This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position.
      Benefits (see test for details):
       - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2),
       - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}.
       
      TBR=dgozman@chromium.org,rmcilroy@chromium.org,machenbach@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org,devtools-reviews@chromium.org,v8-reviews@googlegroups.com
      # Not skipping CQ checks because original CL landed > 1 day ago.
      Bug: v8:5909
      
      Change-Id: Ie84fa79afeed09e28cf8478ba610a0cfbfdfc294
      Reviewed-on: https://chromium-review.googlesource.com/518116
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45598}
      fb6a094d
  13. 29 May, 2017 1 commit
    • Michael Achenbach's avatar
      Revert "[inspector] moved var initialization break location before init expression" · ee1db48c
      Michael Achenbach authored
      This reverts commit 7a9cc704.
      
      Reason for revert: Changes layout tests:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/15882
      
      This is about:
      inspector/sources/debugger/source-frame-inline-breakpoint-decorations.html
      
      Original change's description:
      > [inspector] moved var initialization break location before init expression
      > 
      > This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position.
      > Benefits (see test for details):
      > - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2),
      > - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}.
      > 
      > Bug: v8:5909
      > Change-Id: I039d911903a2826c9859710a63ab0462c992e11b
      > Reviewed-on: https://chromium-review.googlesource.com/513926
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45530}
      
      TBR=dgozman@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org
      # Not skipping CQ checks because original CL landed > 1 day ago.
      Bug: v8:5909
      
      Change-Id: Ibf84401e8050d3c84db219d983de2c6bba0f697f
      Reviewed-on: https://chromium-review.googlesource.com/518102Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45547}
      ee1db48c
  14. 25 May, 2017 1 commit
  15. 24 May, 2017 1 commit
    • kozyatinskiy's avatar
      [inspector] removed call break location from for-of loop · fb78710c
      kozyatinskiy authored
      There are two break locations at the same source location by desugaring:
      - call iterator.next,
      - before variable assignment.
      
      Additionally location for for..of loops is moved from before "of" to before each variable expression.
      
      We should not report first implicit call to avoid user confusion. User still able to go into .next function with both scenarios:
      - when this call is reached by stepOver or stepInto from previous line,
      - when this call is reached because of breakpoint at current line.
      
      BUG=v8:6425
      R=dgozman@chromium.org,jgruber@chromium.org
      
      Review-Url: https://codereview.chromium.org/2893313002
      Cr-Commit-Position: refs/heads/master@{#45509}
      fb78710c
  16. 18 May, 2017 1 commit
    • Adam Klein's avatar
      Reland: [ignition] Be smarter about register allocation in VisitSuspend · 5dc2d6f6
      Adam Klein authored
      Split BytecodeGenerator::VisitSuspend into two pieces, one for
      building the suspension code and one for resumption (these
      are split into separate Build methods for convenience).
      Each gets its own RegisterAllocationScope, which allows us to
      reduce the register file size of the empty generator by 1.
      
      For consistency, rename VisitGeneratorPrologue() to
      BuildGeneratorPrologue() to match the names of the two
      newly-created methods.
      
      This relands the patch originally committed in
      98927ea5, as the test failure
      due to that change was a code flushing bug. Code flushing was
      disabled in de4a4095.
      
      R=rmcilroy@chromium.org
      
      Bug: v8:6379
      Change-Id: Ifb4deafea99693c0a4e8646cf4e9884c7374cfc6
      Reviewed-on: https://chromium-review.googlesource.com/508814Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45406}
      5dc2d6f6
  17. 15 May, 2017 2 commits
  18. 04 May, 2017 1 commit
    • Caitlin Potter's avatar
      [es6] don't use do-expressions to desugar ES6 classes · c6540ab1
      Caitlin Potter authored
      Removes the do-expression wrapping, modifies BytecodeGenerator change
      to enter a class literal's block scope if needed.
      
      This does not solve the actual bug in v8:6322, but helps mitigate it in
      simple cases. The bug is caused by BytecodeGenerator not allocating a
      large enough array of context registers to hold its entire stack,
      allowing non-context registers to be overwritten during PushContext and
      PopContext bytecodes.
      
      Nevertheless, I like the idea of not depending on do-expressions when
      possible, so I think it's worth doing anyways.
      
      BUG=v8:6322
      R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org
      
      Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a
      Reviewed-on: https://chromium-review.googlesource.com/491074
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarDaniel Ehrenberg <littledan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45110}
      c6540ab1
  19. 07 Mar, 2017 1 commit
  20. 06 Mar, 2017 1 commit
  21. 27 Feb, 2017 1 commit