Commits on Sep 13, 2021

1. Optimize Func::call and its C API …

   This commit is an alternative to bytecodealliance#3298 which achieves effectively the
   same goal of optimizing the `Func::call` API as well as its C API
   sibling of `wasmtime_func_call`. The strategy taken here is different
   than bytecodealliance#3298 though where a new API isn't created, rather a small tweak to
   an existing API is done. Specifically this commit handles the major
   sources of slowness with `Func::call` with:
   
   * Looking up the type of a function, to typecheck the arguments with and
     use to guide how the results should be loaded, no longer hits the
     rwlock in the `Engine` but instead each `Func` contains its own
     `FuncType`. This can be an unnecessary allocation for funcs not used
     with `Func::call`, so this is a downside of this implementation
     relative to bytecodealliance#3298. A mitigating factor, though, is that instance
     exports are loaded lazily into the `Store` and in theory not too many
     funcs are active in the store as `Func` objects.
   
   * Temporary storage is amortized with a long-lived `Vec` in the `Store`
     rather than allocating a new vector on each call. This is basically
     the same strategy as bytecodealliance#3294 only applied to different types in
     different places. Specifically `wasmtime::Store` now retains a
     `Vec<u128>` for `Func::call`, and the C API retains a `Vec<Val>` for
     calling `Func::call`.
   
   * Finally, an API breaking change is made to `Func::call` and its type
     signature (as well as `Func::call_async`). Instead of returning
     `Box<[Val]>` as it did before this function now takes a
     `results: &mut [Val]` parameter. This allows the caller to manage the
     allocation and we can amortize-remove it in `wasmtime_func_call` by
     using space after the parameters in the `Vec<Val>` we're passing in.
     This change is naturally a breaking change and we'll want to consider
     it carefully, but mitigating factors are that most embeddings are
     likely using `TypedFunc::call` instead and this signature taking a
     mutable slice better aligns with `Func::new` which receives a mutable
     slice for the results.
   
   Overall this change, in the benchmark of "call a nop function from the C
   API" is not quite as good as bytecodealliance#3298. It's still a bit slower, on the
   order of 15ns, because there's lots of capacity checks around vectors
   and the type checks are slightly less optimized than before. Overall
   though this is still significantly better than today because allocations
   and the rwlock to acquire the type information are both avoided. I
   personally feel that this change is the best to do because it has less
   of an API impact than bytecodealliance#3298.

   

   alexcrichton committed Sep 13, 2021
   Configuration menu

   • View commit details
   • Copy full SHA for 07c563d
   • Browse repository at this point

   Copy the full SHA

   07c563d View commit details

   Browse the repository at this point in the history

2. Rebase issues

   

   alexcrichton committed Sep 13, 2021
   Configuration menu

   • View commit details
   • Copy full SHA for 3ed9019
   • Browse repository at this point

   Copy the full SHA

   3ed9019 View commit details

   Browse the repository at this point in the history