Casting continuations

[tlively]

I remember at some point @rossberg argued that continuation values should not carry runtime type information and therefore should not be able to be cast via ref.cast or other cast instructions. But this is not mentioned in the explainer.

I would strongly prefer to maintain the invariant that references to all heap types can be cast. Binaryen frequently performs transformations where static type information is lost or where it has otherwise inferred more specific types than is available to validation. In these cases, Binaryen depends on being able to insert a cast to preserve the validity of the program. Being able to use casts to recover more specific type information uniformly for all references is important for keeping this code from being riddled with special cases. Presumably other producers have similar needs.

[rossberg]

Such a requirement would interfere quite badly with implementation techniques for allocation-free suspending or binding, because they depend on the same underlying physical object being able to represent multiple logical objects of different type at the same time. It would likely make them more expensive or even impossible, depending on how hacky a cast semantics we'd be willing to end up with.

(The slippery slope of promoting the expectation that all future reference objects are fully self-describing was one of the concerns I raised about the late-stage redesign of casts. In that sense it even is kind of valuable to kill this expectation now rather than later. :) )

[fgmccabe]

In fact, there is a partial way to incorporate the type of the continuation in the allocation-free implementation: along with the counter that establishes the validity of the continuation value that is stored in the stack object you can also store the index of the continuation type.
It's partial because when the continuation value is invalidated, then it's type information would also be lost. The net effect would be to allow casting of a valid continuation value but not of invalid continuation values.

[rossberg]

Yes, hence my alluding to hacky cast semantics. :)

[tlively]

I guess the solution of making wide pointers even wider by including type information along with the sequence counter and continuation pointer falls into the "more expensive" bucket.

[tlively]

Another hacky semantics would be to allow all stale references to the same underlying continuation to be castable to its current type, no matter their original types. This would not fully solve the problem for producers, though, since casts could not be safely introduced to recover type information if the type of the underlying continuation could change in between the point where the type information is lost and the point where the cast would be inserted to recover it.

[tlively]

Another thought: if we don't want to allow casting continuations, then we might want to tack on new versions of br_if, br_table, and maybe local.tee that take type immediates. This would let producers (like Binaryen) that want to model these instructions using the more refined types of their operands do so without having to emit extra casts during binary writing.

[kripken]

My 2c here:

• As Thomas wrote, making certain reference types non-castable would be a significant amount of work in Binaryen.
• I get that the fat-pointer/allocation-free approach would get more overhead if we allowed casts, which is unfortunate.
• But, the even larger point for me is that we support casts on functions. This is quite useful sometimes! Continuations, like functions, take inputs and return outputs, and so being able to ref.test and ref.cast them feels similarly useful. Disallowing that feels inconsistent, and would make some things harder to express.

[fgmccabe]

I don't think that it is a simple as "getting more overhead" with the fat pointer implementation. It may be that the fat pointer implementation approach is no longer possible -- primarily due to security/engine integrity concerns. If the type value becomes part of the 'fat triple', then it is subject to being corrupted whilst being within the sandbox. (This is V8's sandbox, not Wasm's sandbox). A corrupted type can lead to type confusion and enable additional vulnerabilities.

If this analysis is correct, then the true cost of allowing type casting would be a greater overhead for stack switching.

Although there are parallels with functions, continuations get generated at a 'faster rate' than functions: more like closures than functions in this case.

[tlively]

Casts are not trusted operations in the V8 sandbox model, so allowing casts on continuations would not introduce any cost with regards to the sandbox. Actually resuming a continuation needs to do a trusted signature check either way.

[fgmccabe]

Does that imply two casts? Shades of NPE in Java.

[tlively]

If you mean would there be two different kinds of casts, then yes, there would be the sandbox signature check and separately the userspace casts. This is no different than the situation with e.g. function references. If you mean would there necessarily be two casts at runtime, then no, the only required "cast" is the sandbox signature check. The question here is whether userspace is allowed to separately do its own casts for its own purposes. Nothing would require userspace to use casts if it didn't want to.

[fgmccabe]

If there is a cast in user space, then this would be duplicated ... unless the engine is smart enough to avoid the repetition.
Where the cast devolves to a simple type comparison, this is equivalent to the 'double null check' that took >10 years to get rid of in the JVM.
Where the cast is actually a full sub-type check, then this is much more expensive.

[tlively]

Sure, but casts are a well established and well used part of the language for all existing reference types. Offline optimizers and engines already optimize to avoid repeated casts where possible. These general concerns about cast performance are not specific to continuation references and do not justify a different treatment of continuation references and other references.

Let's focus on the details that are specific to continuation references, such as the need for triply-fat pointers in fat pointer implementations.

[kripken]

Do we have a sense of the overhead of "fatter" pointers?

At least in optimizing tiers, it seems practical to remove the type when there are no casts or escaping values (as the type will not have any uses).