feat(jsruntime): async/await

[masnagam]

in this ticket, we implement async and await but we don't implement Promise.

[masnagam]

wikipedia:

• Coroutine

llvm coroutines:

• Coroutines in LLVM
• 2016 LLVM Developers’ Meeting: G. Nishanov “LLVM Coroutines”
  • https://llvm.org/devmtg/2016-11/Slides/Nishanov-LLVMCoroutines.pdf
• CppCon 2016: Gor Nishanov “C++ Coroutines: Under the covers"
• 2018 LLVM Developers’ Meeting: J. McCall “Coroutine Representations and ABIs in LLVM”
• https://bugs.llvm.org/show_bug.cgi?id=36578
  • hmm...

    I'm no longer subscribed to this bug report. I've come to the conclusion that LLVM's coroutine API is not worth using, and resorting to implementing coroutines directly in the frontend.

v8:

• Faster async functions and promises

rust:

• Why async Rust?
• Under the Hood: Executing Futures and Tasks - Asynchronous Programming in Rust
• lowering async await in rust

swift:

• Why stackless (async/await) for Swift?
• 2021 LLVM Dev Mtg “Asynchronous Functions in Swift”
  • slides

zig supports async/await:

• What is the status of async in Zig?
  • the original post on reddit

    LLVM coroutines are just bad -- they optimize poorly, explode compile times, and add implicit calls to malloc.

• What is Zig's “Colorblind” Async/Await?
• The Coroutine Rewrite Issue

kotlin:

• Continuation Passing Style

nim-cps:

• https://github.com/nim-works/cps/blob/master/docs/cps.svg

[masnagam]

i decided not to use llvm.coro.* intrinsics:

• we plan to switch IR to others written in Rust, such as cranelift IR
  • it's better to use only instructions that commonly used in others
• optimizer for llvm.coro.* is great but it does not improve instructions generated from a JavaScript program
  • in many cases, we cannot do inlining JavaScript functions because these are bound to mutable variables and can be changed at runtime
  • of course, functions bound to immutable variables declared with const can be done inlining at compile time, but it's probably minority cases

[masnagam]

basically, existing javascript engines process a javascript module like this:

// The evaluation the source text of the module returns a promise object
// if the source text contains top-level `await` expressions.
runtime.evaluate(&source_text);

// Process all jobs.
runtime.process_jobs();

• v8
  • v8::Script::Run()
  • v8::platform::PumpMessageLoop()
• quickjs
  • JS_Eval()
  • js_std_loop()
• boa
  • Module::load_link_evaluate()
  • Context::run_jobs()

This is a common design pattern that our javascript engine should follow.