• 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
ForOfLoop.golden 45.8 KB