s/cont.new/cont.run/g

[fgmccabe]

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.

[slindley]

I'm just trying to understand what you're proposing here.

Are you suggesting replacing cont.new with a run instruction whose semantics is almost the same as resume except that in place of a continuation reference it takes a function reference?

So a simplified typing rule for run would look something like this (ignoring subtyping for now):

run $ft hdl* : [t1* (ref $ft)] -> [t2*]
where:
- $ft = func [t1*] -> [t2*]

[fgmccabe]

Yes, that would be consistent with my idea.

[tlively]

What if instead of treating a suspend like a call, you treat it like a return followed by a new entry? The values sent along with a suspension would use the returning part of the calling convention and the values sent along with a resume would use the calling part of the calling convention. When a new continuation is created with cont.new, its real preamble would handle receiving the initial resumption values using the same ABI used when resuming from other suspensions.

[fgmccabe]

From the pov of a function, a call sequence is always on the side of the caller, not the callee. I.e., it consists of loading up values in order to pass them. OTOH, returning from a suspend involves unloading the results (typically into local variables).

In addition, it would not allow us to use the same suite of registers for the data being passed to Suspend. In V8, return values are passed on the stack (if there is more than one of them).

[tlively]

@slindley or @frank-emrich, how does wasmtime deal with initial resumptions of continuations looking different from subsequent resumptions?

[frank-emrich]

In our stack switching implementation, we always transferred payloads (e.g., the arguments and return values of a continuations, arguments to suspend, etc) using dedicated buffers, allocated directly on one of the involved stacks.

This was easy because for every function, Wasmtime already compiles a trampoline for running the function such that it reads the arguments from a buffer and writes the return values there, too.

This means that on resume, we do check a flag inside the continuation to see if it "fresh" (= created by cont.new) or not (created by suspend or switch). But that flag is only needed to determine the address of the buffer to read from/write to. I'm fairly sure that we could get rid of that branch altogether, meaning that the code generated for resume is completely agnostic of whether the continuation was created by cont.new or not.

[titzer]

Wizard has a special stub for a fresh continuation called the enter-func-stub and the stack object has a slot that points to the function. The value stack is stored separately and arguments are just put into the normal argument slots. Both suspended and fresh continuations are resumed the same way--push the arguments, switch the stack and frame pointers, and jump to the instruction pointer stored in the stack. The enter-func-stub just loads the function from the stack and does the normal frame setup. While it'd be possible to set up the target function's frame partially in cont.new, it doesn't really save any work AFAICT. One good reason for not setting up the target function's frame is that between cont.new and eventually resuming the continuation, the engine might have tiered the function up (or down). The enter-func-stub ensures that resume-ing the target function will enter using the frame setup for the correct tier.

This proposal seems like a premature optimization that will only save a small number of instructions and seems more appropriate as an optimizing compiler transform.

[fgmccabe]

@titzer The issue is not one of 'premature optimization'. It is actually about the mismatch between the way that a continuation is resumed (by leaving stuff on the stack) and the way a function is entered (by having stuff in arguments).
In the case of V8, in order to account for this we will have to add an extra pass to the compiler to generate stubs for cont.new: i.e., this implies a nasty change to the architecture of V8's compiler.

[titzer]

In the V8 compiler you can use a CallDescriptor to make suspend bytecodes return their results in the same argument registers as an incoming function call would use, so that resume can always pass the outgoing arguments in the same registers. The stub I mentioned above takes care of loading any bound arguments from the continuation into registers if needed.

You could probably obviate the need for a stub by partially setting up the frame in cont.new so that resume could just pass arguments and jump to the entrypoint of the function (stored in the stack object).

[fgmccabe]

This seems backwards.
In the case of a normal resume, the resumee will be expecting the 'return' from the suspend on the stack - just as as a function call.
In the case of a normal function entry, the arguments are already preallocated to specific local variables. This is not the case for handling the return from a function call or the return from a suspend.

Note that wasm 'could have' been designed differently:
a. On entry, the arguments to a function could be 'on the stack'
b. Every function call could also specify where the return values go.

Either one of these would not have the same architectural implications that cont.new has.

For a historical perspective: the first is how Forth works and the second is how Prolog engines work.

But, that is all moot. What we have requires constructing special stub functions -- just for the cont.new instruction. My issue is that this is special casing just one instruction.