Implement asynchronous evaluation of scripts

[jedel1043]

This Pull Request implements and API to asynchronously run scripts.
Had to do some refactoring in order to share code between run and run_async_with_budget, but I ran the QuickJS benchmark and everything looks good!

However, our engine has a big limitation right now: we cannot track the executed instructions of called functions because those internally use run. For this reason, this PR just tracks instructions executed in the root script being executed, but this can be implemented in the future. Solved by #3295

Some context

We have used this pattern of freely calling run inside several functions because it's easy to reason about, and Context owns the current VM state. However, it is really unusual to have VM state inside a shared Context, and using run this way causes problems that we've already seen but ignored, like duplicate prints of functions' bytecode when using tracing.

If we can pull off the separation of the VM from the Context, we could even make the context reference we pass to every function an immutable one (&Context<'_>), which will unblock a LOT of patterns that we've been largely working around.

Having said that, I have some ideas on how to make this work. This will probably involve changing the return value of our functions and some generator shenanigans, but I found an interesting crate that implements them using async/await, which makes them available on stable code (https://github.com/whatisaphone/genawaiter).

I'm open to any other ideas you have! The gist of problem is: "How to bubble up JS function calls to the original Context::run call".

Anyways, sorry for the info dump.

[github-actions]

Test262 conformance changes

Test result	main count	PR count	difference
Total	95,609	95,609	0
Passed	75,690	75,690	0
Ignored	19,160	19,160	0
Failed	759	759	0
Panics	0	0	0
Conformance	79.17%	79.17%	0.00%

[codecov]

Codecov Report

Attention: 68 lines in your changes are missing coverage. Please review.

Comparison is base (1d66836) 45.78% compared to head (3236b28) 45.73%.
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3044      +/-   ##
==========================================
- Coverage   45.78%   45.73%   -0.06%     
==========================================
  Files         483      483              
  Lines       49349    49427      +78     
==========================================
+ Hits        22594    22603       +9     
- Misses      26755    26824      +69     

Files	Coverage Δ
boa_engine/src/vm/opcode/await/mod.rs	73.75% <ø> (ø)
boa_engine/src/vm/opcode/binary_ops/logical.rs	100.00% <ø> (ø)
...a_engine/src/vm/opcode/binary_ops/macro_defined.rs	85.71% <ø> (ø)
boa_engine/src/vm/opcode/binary_ops/mod.rs	57.37% <ø> (ø)
boa_engine/src/vm/opcode/call/mod.rs	21.73% <ø> (ø)
boa_engine/src/vm/opcode/concat/mod.rs	70.00% <ø> (ø)
boa_engine/src/vm/opcode/control_flow/jump.rs	97.56% <ø> (ø)
boa_engine/src/vm/opcode/control_flow/return.rs	68.42% <ø> (ø)
boa_engine/src/vm/opcode/control_flow/throw.rs	41.02% <ø> (ø)
boa_engine/src/vm/opcode/copy/mod.rs	46.66% <ø> (ø)
... and 55 more

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[raskad]

@HalidOdat you mentioned in #2904 that you wanted to refactor how we call functions to not recurse on the rust side. That would probably impact the design of this feature right?

[jedel1043]

Ah, seems like @HalidOdat and I arrived at the same problem from two different but related features. We could probably solve both problems using the same solution then :)

[HalidOdat]

I'm open to any other ideas you have! The gist of problem is: "How to bubble up JS function calls to the original Context::run call?".

The solution I thought of was to have only one run. we have a function that is called before every run (prepare_vm_call or something like this) that pushes the call frame and anything else that is needed, then we call run (which just runs instructions in a loop, the run does not call the prepare function)

The Opcode::Call instructions would only prepare the vm and continue with next instruction, because the frame is pushed we automatically get the instruction from the called function.

How do we know if we should return or continue executing until we run out of call frames?

For this we can have a flag in the call frame that returns in run.

This would greatly simplify our calling logic! Not having to do a clone of the passed arguments and reversing them and pushing them back again instead just using the ones that where already pushed by the Opcodes. Not creating separate value and environment stacks (for ordinary functions at least).

Note: This stops recursion (and causing a stack overflow) from JavaScript, You can still recurse in rust, by recursively calling a function that calls object.call(.., context).

[jedel1043]

That sounds perfect to avoid recursing inside JS functions. We could implement that first, then think about how to avoid recursing inside Rust functions next.

[HalidOdat]

Looks good! Just an memory optimization

I don't think this addition would make the call refactor any harder :)

[HalidOdat]

Looks good to me! :)

We can reduce the spend function table which I did in #3401, we can merge this first, or merge into this?

[jedel1043]

we can merge this first, or merge into this?

Let's just merge it into this, since they're related changes :)

[nekevss]

Nice work! I like the updates! 😄