97894bc65e
* Add initial support for fused adapter trampolines This commit lands a significant new piece of functionality to Wasmtime's implementation of the component model in the form of the implementation of fused adapter trampolines. Internally within a component core wasm modules can communicate with each other by having their exports `canon lift`'d to get `canon lower`'d into a different component. This signifies that two components are communicating through a statically known interface via the canonical ABI at this time. Previously Wasmtime was able to identify that this communication was happening but it simply panicked with `unimplemented!` upon seeing it. This commit is the beginning of filling out this panic location with an actual implementation. The implementation route chosen here for fused adapters is to use a WebAssembly module itself for the implementation. This means that, at compile time of a component, Wasmtime is generating core WebAssembly modules which then get recursively compiled within Wasmtime as well. The choice to use WebAssembly itself as the implementation of fused adapters stems from a few motivations: * This does not represent a significant increase in the "trusted compiler base" of Wasmtime. Getting the Wasm -> CLIF translation correct once is hard enough much less for an entirely different IR to CLIF. By generating WebAssembly no new interactions with Cranelift are added which drastically reduces the possibilities for mistakes. * Using WebAssembly means that component adapters are insulated from miscompilations and mistakes. If something goes wrong it's defined well within the WebAssembly specification how it goes wrong and what happens as a result. This means that the "blast zone" for a wrong adapter is the component instance but not the entire host itself. Accesses to linear memory are guaranteed to be in-bounds and otherwise handled via well-defined traps. * A fully-finished fused adapter compiler is expected to be a significant and quite complex component of Wasmtime. Functionality along these lines is expected to be needed for Web-based polyfills of the component model and by using core WebAssembly it provides the opportunity to share code between Wasmtime and these polyfills for the component model. * Finally the runtime implementation of managing WebAssembly modules is already implemented and quite easy to integrate with, so representing fused adapters with WebAssembly results in very little extra support necessary for the runtime implementation of instantiating and managing a component. The compiler added in this commit is dubbed Wasmtime's Fused Adapter Compiler of Trampolines (FACT) because who doesn't like deriving a name from an acronym. Currently the trampoline compiler is limited in its support for interface types and only supports a few primitives. I plan on filing future PRs to flesh out the support here for all the variants of `InterfaceType`. For now this PR is primarily focused on all of the other infrastructure for the addition of a trampoline compiler. With the choice to use core WebAssembly to implement fused adapters it means that adapters need to be inserted into a module. Unfortunately adapters cannot all go into a single WebAssembly module because adapters themselves have dependencies which may be provided transitively through instances that were instantiated with other adapters. This means that a significant chunk of this PR (`adapt.rs`) is dedicated to determining precisely which adapters go into precisely which adapter modules. This partitioning process attempts to make large modules wherever it can to cut down on core wasm instantiations but is likely not optimal as it's just a simple heuristic today. With all of this added together it's now possible to start writing `*.wast` tests that internally have adapted modules communicating with one another. A `fused.wast` test suite was added as part of this PR which is the beginning of tests for the support of the fused adapter compiler added in this PR. Currently this is primarily testing some various topologies of adapters along with direct/indirect modes. This will grow many more tests over time as more types are supported. Overall I'm not 100% satisfied with the testing story of this PR. When a test fails it's very difficult to debug since everything is written in the text format of WebAssembly meaning there's no "conveniences" to print out the state of the world when things go wrong and easily debug. I think this will become even more apparent as more tests are written for more types in subsequent PRs. At this time though I know of no better alternative other than leaning pretty heavily on fuzz-testing to ensure this is all exercised. * Fix an unused field warning * Fix tests in `wasmtime-runtime` * Add some more tests for compiled trampolines * Remap exports when injecting adapters The exports of a component were accidentally left unmapped which meant that they indexed the instance indexes pre-adapter module insertion. * Fix typo * Rebase conflicts
97 lines
4.0 KiB
Rust
97 lines
4.0 KiB
Rust
use serde::{Deserialize, Serialize};
|
|
|
|
/// Tunable parameters for WebAssembly compilation.
|
|
#[derive(Clone, Hash, Serialize, Deserialize)]
|
|
pub struct Tunables {
|
|
/// For static heaps, the size in wasm pages of the heap protected by bounds checking.
|
|
pub static_memory_bound: u64,
|
|
|
|
/// The size in bytes of the offset guard for static heaps.
|
|
pub static_memory_offset_guard_size: u64,
|
|
|
|
/// The size in bytes of the offset guard for dynamic heaps.
|
|
pub dynamic_memory_offset_guard_size: u64,
|
|
|
|
/// The size, in bytes, of reserved memory at the end of a "dynamic" memory,
|
|
/// before the guard page, that memory can grow into. This is intended to
|
|
/// amortize the cost of `memory.grow` in the same manner that `Vec<T>` has
|
|
/// space not in use to grow into.
|
|
pub dynamic_memory_growth_reserve: u64,
|
|
|
|
/// Whether or not to generate native DWARF debug information.
|
|
pub generate_native_debuginfo: bool,
|
|
|
|
/// Whether or not to retain DWARF sections in compiled modules.
|
|
pub parse_wasm_debuginfo: bool,
|
|
|
|
/// Whether or not fuel is enabled for generated code, meaning that fuel
|
|
/// will be consumed every time a wasm instruction is executed.
|
|
pub consume_fuel: bool,
|
|
|
|
/// Whether or not we use epoch-based interruption.
|
|
pub epoch_interruption: bool,
|
|
|
|
/// Whether or not to treat the static memory bound as the maximum for unbounded heaps.
|
|
pub static_memory_bound_is_maximum: bool,
|
|
|
|
/// Whether or not linear memory allocations will have a guard region at the
|
|
/// beginning of the allocation in addition to the end.
|
|
pub guard_before_linear_memory: bool,
|
|
|
|
/// Indicates whether an address map from compiled native code back to wasm
|
|
/// offsets in the original file is generated.
|
|
pub generate_address_map: bool,
|
|
|
|
/// Flag for the component module whether adapter modules have debug
|
|
/// assertions baked into them.
|
|
pub debug_adapter_modules: bool,
|
|
}
|
|
|
|
impl Default for Tunables {
|
|
fn default() -> Self {
|
|
let (static_memory_bound, static_memory_offset_guard_size) =
|
|
if cfg!(target_pointer_width = "64") {
|
|
// 64-bit has tons of address space to static memories can have 4gb
|
|
// address space reservations liberally by default, allowing us to
|
|
// help eliminate bounds checks.
|
|
//
|
|
// Coupled with a 2 GiB address space guard it lets us translate
|
|
// wasm offsets into x86 offsets as aggressively as we can.
|
|
(0x1_0000, 0x8000_0000)
|
|
} else if cfg!(target_pointer_width = "32") {
|
|
// For 32-bit we scale way down to 10MB of reserved memory. This
|
|
// impacts performance severely but allows us to have more than a
|
|
// few instances running around.
|
|
((10 * (1 << 20)) / crate::WASM_PAGE_SIZE as u64, 0x1_0000)
|
|
} else {
|
|
panic!("unsupported target_pointer_width");
|
|
};
|
|
Self {
|
|
static_memory_bound,
|
|
static_memory_offset_guard_size,
|
|
|
|
// Size in bytes of the offset guard for dynamic memories.
|
|
//
|
|
// Allocate a small guard to optimize common cases but without
|
|
// wasting too much memory.
|
|
dynamic_memory_offset_guard_size: 0x1_0000,
|
|
|
|
// We've got lots of address space on 64-bit so use a larger
|
|
// grow-into-this area, but on 32-bit we aren't as lucky.
|
|
#[cfg(target_pointer_width = "64")]
|
|
dynamic_memory_growth_reserve: 2 << 30, // 2GB
|
|
#[cfg(target_pointer_width = "32")]
|
|
dynamic_memory_growth_reserve: 1 << 20, // 1MB
|
|
|
|
generate_native_debuginfo: false,
|
|
parse_wasm_debuginfo: true,
|
|
consume_fuel: false,
|
|
epoch_interruption: false,
|
|
static_memory_bound_is_maximum: false,
|
|
guard_before_linear_memory: true,
|
|
generate_address_map: true,
|
|
debug_adapter_modules: false,
|
|
}
|
|
}
|
|
}
|