1. 06 Dec, 2018 1 commit
    • tzik's avatar
      Replace %RunMicrotasks with %PerformMicrotaskCheckpoint · 07011cc4
      tzik authored
      This replaces Runtime_RunMicrotasks with Runtime_PerformMicrotaskCheckpoint.
      
      RunMicrotasks forcibly runs Microtasks even when the microtasks are suppressed,
      and may causes nested Microtasks in a problematic way. E.g. that confuses
      v8::MicrotasksScope::IsRunningMicrotasks() and GetEnteredOrMicrotaskContext().
      
      OTOH, PerformMicrotaskCheckpoint() doesn't run cause the failure as it
      respects the microtask suppressions.
      
      As all existing tests don't call RunMicrotasks() in the suppressed situation
      (like Promise.resolve().then(()=>{%RunMicrotasks();})), this change should
      not affect to these tests.
      
      Change-Id: Ib043a0cc8e482e022d375084d65ea98a6f54ef3d
      Reviewed-on: https://chromium-review.googlesource.com/c/1360095Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58068}
      07011cc4
  2. 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
  3. 18 Jul, 2017 1 commit
  4. 31 May, 2017 1 commit
  5. 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
  6. 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
  7. 25 May, 2017 1 commit
  8. 10 Jan, 2017 1 commit
  9. 08 Nov, 2016 1 commit
  10. 07 Nov, 2016 2 commits
  11. 03 Jun, 2016 1 commit