More fine-grained tracking of continuations' states

[frank-emrich]

This PR is part of an effort to implement more efficient effect forwarding.

This particular PR makes our tracking of the state of continuations more fine-grained. Currently, the State enum only allows us to distinguish three cases:

1. A continuation was allocated, but never invoked (State::Allocated).
2. A continuation has been invoked at some point, and not returned, yet (State::Invoked).
3. A continuation has returned (State::Returned).

This PR replaces State::Invoked with three new states, indicating more closely what's going on:

• State::Running indicates that the continuation is the one currently executing code
• State::Parent indicates that a continuation is suspended because it resumed another one.
• State::Suspended indicates that a continuation was suspended directly (i.e., by calling suspend, or in the future switch)

This PR incurrs a few additional stores per stack switch, for example because on resume we now need to update the state of the resumee and its new parent. On our usual benchmarks (in particular, state), this has no measurable effect. However, the two benchmarks in the micro subfolder see a 5-10% regression. Interestingly, this doesn't seem to be caused by the instructions responsible for the additional state updates (I experimented with not updating the parent states), but just some result of instructions being scheduled slightly differently after applying this PR. In any case, this regression seems acceptable anyway.

This PR also extends the information we track about the main stack to carry a State. Otherwise we would need to check whenever we want to update the State of the parent if the parent is the main stack or another continuation.

[dhil]

Can you explain the rationale for these states? What are their relevance to effect forwarding?

[frank-emrich]

In the future, every Suspended continuation will have a pointer to the end of the continuation chain (i.e., its "oldest" ancestor) and each Parent stack has a list of (tag_id, handler block) pairs that it handles. Having the more explicit states is mostly a matter of debuggability, making it easier to express and enforce these invariants.

[dhil]

Thanks!

[dhil]

I'm wondering whether those assertions should in fact be debug_assert!?

[frank-emrich]

@dhil

I'm wondering whether those assertions should in fact be debug_assert!?

Not sure if I understand this. Did you mean to comment this on a particular line?

[dhil]

@dhil

I'm wondering whether those assertions should in fact be debug_assert!?

Not sure if I understand this. Did you mean to comment this on a particular line?

I mean, we have many assert!s in the code, I wonder whether they should in fact be debug_assert!s.