Closed pchickey closed 2 years ago
Okay, just to make sure I understand, we will no longer get a runtime error back from Instance::run_async
when the heap is exhausted. Instead, we'll set up some mechanism in a MemoryLimiter
impl that keeps track of whether the heap has been exhausted, and then check+translate that into an embedder-specific error after the run completes?
Yes, exactly that.
Lucet's
Instance::terminate_on_heap_oom
behavior was, from the beginning (https://github.com/bytecodealliance/lucet/pull/583), something that deviated from the Wasm spec. This PR eliminates it in favor of a different mechanism,MemoryLimiter
.MemoryLimiter::memory_growing
provides users a mechanism to allow or disallow amemory.grow
operation, as well asawait
on memory becoming available.terminate_on_heap_ppm
is replaced by theMemoryLimiter::memory_grow_failed
method, where an unsuccessful grow (whether due tomemory_growing
,Limits
, or an OS memory allocation failure) is reported to the embedder.When we went to add heap-out-of-memory detection in Wasmtime, we had to figure out a way to do so without breaking the spec, and that turned into
ResourceLimiter
.Here in Lucet, I introduced
MemoryLimiter
, which only does the memory-related operations of wasmtime's ResourceLimiter.Unlike in Wasmtime, where we went to some pains to make it work with both sync and async embeddings, this embedding only works for async, because that is what Fastly's embedding needs and we aren't putting energy into generalizing the features.
Also unlike in Wasmtime, the
MemoryLimiter
doesn't attempt to restrict memory operations by the embedding API (e.g.Instance::grow_memory
), because we don't end up needing it in the Fastly embedding. TheMemoryLimiter
only works on wasmmemory.grow
operations.