Delete historical interruptable support in Wasmtime (#3925)

* Delete historical interruptable support in Wasmtime

This commit removes the `Config::interruptable` configuration along with
the `InterruptHandle` type from the `wasmtime` crate. The original
support for adding interruption to WebAssembly was added pretty early on
in the history of Wasmtime when there was no other method to prevent an
infinite loop from the host. Nowadays, however, there are alternative
methods for interruption such as fuel or epoch-based interruption.

One of the major downsides of `Config::interruptable` is that even when
it's not enabled it forces an atomic swap to happen when entering
WebAssembly code. This technically could be a non-atomic swap if the
configuration option isn't enabled but that produces even more branch-y
code on entry into WebAssembly which is already something we try to
optimize. Calling into WebAssembly is on the order of a dozens of
nanoseconds at this time and an atomic swap, even uncontended, can add
up to 5ns on some platforms.

The main goal of this PR is to remove this atomic swap on entry into
WebAssembly. This is done by removing the `Config::interruptable` field
entirely, moving all existing consumers to epochs instead which are
suitable for the same purposes. This means that the stack overflow check
is no longer entangled with the interruption check and perhaps one day
we could continue to optimize that further as well.

Some consequences of this change are:

* Epochs are now the only method of remote-thread interruption.
* There are no more Wasmtime traps that produces the `Interrupted` trap
  code, although we may wish to move future traps to this so I left it
  in place.
* The C API support for interrupt handles was also removed and bindings
  for epoch methods were added.
* Function-entry checks for interruption are a tiny bit less efficient
  since one check is performed for the stack limit and a second is
  performed for the epoch as opposed to the `Config::interruptable`
  style of bundling the stack limit and the interrupt check in one. It's
  expected though that this is likely to not really be measurable.
* The old `VMInterrupts` structure is renamed to `VMRuntimeLimits`.

crates/cranelift/src/lib.rs

@@ -5,20 +5,20 @@
 
 // # How does Wasmtime prevent stack overflow?
 //
-// A few locations throughout the codebase link to this file to explain
-// interrupts and stack overflow. To start off, let's take a look at stack
-// overflow. Wasm code is well-defined to have stack overflow being recoverable
-// and raising a trap, so we need to handle this somehow! There's also an added
-// constraint where as an embedder you frequently are running host-provided
-// code called from wasm. WebAssembly and native code currently share the same
-// call stack, so you want to make sure that your host-provided code will have
-// enough call-stack available to it.
+// A few locations throughout the codebase link to this file to explain stack
+// overflow. To start off, let's take a look at stack overflow. Wasm code is
+// well-defined to have stack overflow being recoverable and raising a trap, so
+// we need to handle this somehow! There's also an added constraint where as an
+// embedder you frequently are running host-provided code called from wasm.
+// WebAssembly and native code currently share the same call stack, so you want
+// to make sure that your host-provided code will have enough call-stack
+// available to it.
 //
 // Given all that, the way that stack overflow is handled is by adding a
 // prologue check to all JIT functions for how much native stack is remaining.
 // The `VMContext` pointer is the first argument to all functions, and the first
-// field of this structure is `*const VMInterrupts` and the first field of that
-// is the stack limit. Note that the stack limit in this case means "if the
+// field of this structure is `*const VMRuntimeLimits` and the first field of
+// that is the stack limit. Note that the stack limit in this case means "if the
 // stack pointer goes below this, trap". Each JIT function which consumes stack
 // space or isn't a leaf function starts off by loading the stack limit,
 // checking it against the stack pointer, and optionally traps.
@@ -43,50 +43,6 @@
 // For more information about the tricky bits of managing the reserved stack
 // size of wasm, see the implementation in `traphandlers.rs` in the
 // `update_stack_limit` function.
-//
-// # How is Wasmtime interrupted?
-//
-// Ok so given all that background of stack checks, the next thing we want to
-// build on top of this is the ability to *interrupt* executing wasm code. This
-// is useful to ensure that wasm always executes within a particular time slice
-// or otherwise doesn't consume all CPU resources on a system. There are two
-// major ways that interrupts are required:
-//
-// * Loops - likely immediately apparent but it's easy to write an infinite
-//   loop in wasm, so we need the ability to interrupt loops.
-// * Function entries - somewhat more subtle, but imagine a module where each
-//   function calls the next function twice. This creates 2^n calls pretty
-//   quickly, so a pretty small module can export a function with no loops
-//   that takes an extremely long time to call.
-//
-// In many cases if an interrupt comes in you want to interrupt host code as
-// well, but we're explicitly not considering that here. We're hoping that
-// interrupting host code is largely left to the embedder (e.g. figuring out
-// how to interrupt blocking syscalls) and they can figure that out. The purpose
-// of this feature is to basically only give the ability to interrupt
-// currently-executing wasm code (or triggering an interrupt as soon as wasm
-// reenters itself).
-//
-// To implement interruption of loops we insert code at the head of all loops
-// which checks the stack limit counter. If the counter matches a magical
-// sentinel value that's impossible to be the real stack limit, then we
-// interrupt the loop and trap. To implement interrupts of functions, we
-// actually do the same thing where the magical sentinel value we use here is
-// automatically considered as considering all stack pointer values as "you ran
-// over your stack". This means that with a write of a magical value to one
-// location we can interrupt both loops and function bodies.
-//
-// The "magical value" here is `usize::max_value() - N`. We reserve
-// `usize::max_value()` for "the stack limit isn't set yet" and so -N is
-// then used for "you got interrupted". We do a bit of patching afterwards to
-// translate a stack overflow into an interrupt trap if we see that an
-// interrupt happened. Note that `N` here is a medium-size-ish nonzero value
-// chosen in coordination with the cranelift backend. Currently it's 32k. The
-// value of N is basically a threshold in the backend for "anything less than
-// this requires only one branch in the prologue, any stack size bigger requires
-// two branches". Naturally we want most functions to have one branch, but we
-// also need to actually catch stack overflow, so for now 32k is chosen and it's
-// assume no valid stack pointer will ever be `usize::max_value() - 32k`.
 
 use cranelift_codegen::binemit;
 use cranelift_codegen::ir;