s/cont.new/cont.run/g

Start by reading the proposal's existing cont.new, resume, and resume_throw definitions, then trace the V8 compilation and decoding flow described in the issue, including the type and function sections. The work is complete when the design decision for replacing cont.new with cont.run is agreed and the coroutine-creation and never-suspending use cases are addressed.

It turns out that implementing cont.new is not trivial in V8. The reasons have to do with how we want to 'interpret' suspensions and subsequent resumptions.

In normal flow, a resume always follows a suspend. From the pov of a coroutine, the suspend and subsequent 'recovery' on being resumed looks a lot like calling a function:

push a1
..
push ak
push K
suspend tag
local.set r1
..
local.set rm

It is our intention to reuse the existing machinery for function calling to make this pattern as performant as possible.

cont.new does not fall into this pattern, because, instead of the return values from the suspend being on the value stack, they form the arguments to the function itself.

However, when implementing resume, we do not know whether this is the first time a coroutine is being 'woken up' or is actually following a suspend. The code generated for resume must assume the latter.

This implies that we must generate additional code for each occurrence of cont.new just to handle this mismatch. In addition, since the argument to cont.new is a funcref, not a named function, we cannot modify the code of the function itself (e.g., by adding a preamble to the compiled function).

Generating these 'co-wrappers' is a non-trivial change to the compilation flow of V8. We have to decide how to manage the wrappers that we generate and we have to decide when to generate them. Generating them at the point of compiling cont.new requires that the entire compilation chain itself can be recursively reentered and also risks generating a lot of identical looking code. Generating them during decoding (e.g. after decoding the type section and before decoding/compiling the function section) has architectural implications (polluting the compilation pipeline somewhat egregiously).

From a dynamic computation pov, having these co-wrappers is almost equivalent having cont.new automatically entering the newly created coroutine and being immediately suspended.

IMO, a cleaner design that honors reasonable implementation strategies would be to not have cont.new, but to have cont.run; which would be specified as a variant of resume and resume_throw. This would also address an issue that I have raised before: of supporting the use case where coroutines are created but which never suspend.