363cd2d20f
* Expose memory-related options in `Config` This commit was initially motivated by looking more into #1501, but it ended up balooning a bit after finding a few issues. The high-level items in this commit are: * New configuration options via `wasmtime::Config` are exposed to configure the tunable limits of how memories are allocated and such. * The `MemoryCreator` trait has been updated to accurately reflect the required allocation characteristics that JIT code expects. * A bug has been fixed in the cranelift wasm code generation where if no guard page was present bounds checks weren't accurately performed. The new `Config` methods allow tuning the memory allocation characteristics of wasmtime. Currently 64-bit platforms will reserve 6GB chunks of memory for each linear memory, but by tweaking various config options you can change how this is allocate, perhaps at the cost of slower JIT code since it needs more bounds checks. The methods are intended to be pretty thoroughly documented as to the effect they have on the JIT code and what values you may wish to select. These new methods have been added to the spectest fuzzer to ensure that various configuration values for these methods don't affect correctness. The `MemoryCreator` trait previously only allocated memories with a `MemoryType`, but this didn't actually reflect the guarantees that JIT code expected. JIT code is generated with an assumption about the minimum size of the guard region, as well as whether memory is static or dynamic (whether the base pointer can be relocated). These properties must be upheld by custom allocation engines for JIT code to perform correctly, so extra parameters have been added to `MemoryCreator::new_memory` to reflect this. Finally the fuzzing with `Config` turned up an issue where if no guard pages present the wasm code wouldn't correctly bounds-check memory accesses. The issue here was that with a guard page we only need to bounds-check the first byte of access, but without a guard page we need to bounds-check the last byte of access. This meant that the code generation needed to account for the size of the memory operation (load/store) and use this as the offset-to-check in the no-guard-page scenario. I've attempted to make the various comments in cranelift a bit more exhaustive too to hopefully make it a bit clearer for future readers! Closes #1501 * Review comments * Update a comment
59 lines
2.3 KiB
Rust
59 lines
2.3 KiB
Rust
/// Tunable parameters for WebAssembly compilation.
|
|
#[derive(Clone, Hash)]
|
|
pub struct Tunables {
|
|
/// For static heaps, the size in wasm pages of the heap protected by bounds checking.
|
|
pub static_memory_bound: u32,
|
|
|
|
/// 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,
|
|
|
|
/// Whether or not to generate DWARF debug information.
|
|
pub debug_info: bool,
|
|
|
|
/// Whether or not to enable the ability to interrupt wasm code dynamically.
|
|
///
|
|
/// More info can be found about the implementation in
|
|
/// crates/environ/src/cranelift.rs. Note that you can't interrupt host
|
|
/// calls and interrupts are implemented through the `VMInterrupts`
|
|
/// structure, or `InterruptHandle` in the `wasmtime` crate.
|
|
pub interruptable: bool,
|
|
}
|
|
|
|
impl Default for Tunables {
|
|
fn default() -> Self {
|
|
Self {
|
|
#[cfg(target_pointer_width = "32")]
|
|
/// Size in wasm pages of the bound for static memories.
|
|
static_memory_bound: 0x4000,
|
|
#[cfg(target_pointer_width = "64")]
|
|
/// Size in wasm pages of the bound for static memories.
|
|
///
|
|
/// When we allocate 4 GiB of address space, we can avoid the
|
|
/// need for explicit bounds checks.
|
|
static_memory_bound: 0x1_0000,
|
|
|
|
#[cfg(target_pointer_width = "32")]
|
|
/// Size in bytes of the offset guard for static memories.
|
|
static_memory_offset_guard_size: 0x1_0000,
|
|
#[cfg(target_pointer_width = "64")]
|
|
/// Size in bytes of the offset guard for static memories.
|
|
///
|
|
/// Allocating 2 GiB of address space lets us translate wasm
|
|
/// offsets into x86 offsets as aggressively as we can.
|
|
static_memory_offset_guard_size: 0x8000_0000,
|
|
|
|
/// 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,
|
|
|
|
debug_info: false,
|
|
interruptable: false,
|
|
}
|
|
}
|
|
}
|