plugins: every invocation re-faults the guest's linear memory — expose linear_memory_keep_resident on the pooling allocator #376

Summary

Each plugin invocation instantiates a fresh Store from the cached InstancePre with the pooling allocator — cheap — but the pool is configured without linear_memory_keep_resident (plugin/runtime.rs:148, wasmtime default 0), so when an instance is returned its linear memory is reset with madvise and every page the guest touches is faulted in again on the next call.

For a game-engine style plugin called twice per turn (observe, step), each call decodes a ~20–30 KB state, allocates its working bitmaps and builds a JSON answer — the same pages every call.

Measured

Per call in a real loop: observe 0.77 ms, step 0.47 ms mean (plugin_invocation_duration). A native host of the same component (wasmtime, instantiate per call, no pooling) spends ~30–50 µs per call just instantiating.

Proposal

Expose [plugins] linear_memory_keep_resident_bytes (and table_keep_resident) on the pooling config, defaulting to something like the first few MiB, so a warm slot keeps its hot pages. Related and smaller, while here: the resolved input is re-validated against the function's schema and round-tripped through serde_json strings on every call (plugin/handler.rs:157-208) — worth measuring alongside.