WASM 线性内存管理实践：分配器、增长、泄漏与池化

(module
  (memory (export "memory") 16 256)   ;; 初始 16 页 = 1MiB，最大 256 页 = 16MiB
)

关键数字：1 页 = 64 KiB = 65536 字节；32 位地址空间上限 = 65536 页 = 4 GiB
（实际受 MAXIMUM_MEMORY 限制）；memory.grow(n) 返回旧页数，失败返回 -1
（不是 trap）；memory.size 返回当前页数。

典型布局（从低地址到高地址）：栈区（向下增长）→ 静态数据段（.data/.rodata）
→ 堆区（向上增长，由分配器管理）→ 未分配页（grow 后可用）。

# Emscripten 切换分配器
emcc app.c -O2 -sMALLOC=emmalloc -o app.js
# Rust 侧替换全局分配器

// Rust：换成 bump 分配器（无法 free，但极快）
#[global_allocator]
static ALLOC: bumpalo::Bump = bumpalo::Bump::new();

值得自研的场景：固定尺寸对象为主（空闲链表几行代码即可）、生命周期分阶段
（arena/bump 整块释放）、极致体积要求（位图管理固定块）。
不值得：通用负载、对象尺寸混杂 → 用成熟分配器，自研必然更差。

memory.grow 的三个代价：宿主重新分配底层 ArrayBuffer（可能整块拷贝）、
所有 HEAP 视图立即失效、新页必须清零导致大块增长有明显停顿。

// 增长后视图失效的真实表现
let view = new Uint8Array(Module.memory.buffer, 0, 16);
Module._alloc_big();                       // 内部触发 grow
view[0] = 1;                               // TypeError: detached ArrayBuffer

# 一次性预留足够内存，避免运行期增长
emcc app.c -O2 -sINITIAL_MEMORY=256MB -sMAXIMUM_MEMORY=256MB \
  -sALLOW_MEMORY_GROWTH=0 -o app.js

固定大小（禁止增长）：最快、视图永不失效，超出即 OOM；
允许增长 + 小初始值：启动快、内存省，但运行期有停顿与视图失效；
预分配 + 允许增长：折中，初始给够，增长作为兜底。

外部碎片：空闲块被切碎，总空闲足够但无连续大块 → 尺寸分级 + arena 隔离；
内部碎片：分配块大于实际需求 → 调整分级粒度，权衡碎片与查找速度。

典型外部碎片场景：分配 A(1KB) B(4KB) C(1KB) 后释放 B，留下 4KB 空洞；
此时申请 3KB 会失败（无连续 3KB），但总空闲其实有 4KB。

对齐规则：i32.load 建议 4 字节、i64.load 建议 8 字节、v128.load 要求 16 字节；
结构体成员按最大成员对齐（与 C 一致）。SIMD 在非对齐地址上会直接 trap。

// 显式声明对齐，避免 SIMD 加载 trap
#[repr(C, align(16))]
struct Aligned4x4 { data: [f32; 16] }

五类典型泄漏：malloc 后忘记 free（C/C++ 最常见）、跨边界返回的指针 JS 侧
忘记 _free、注册回调后未 removeFunction（函数表泄漏）、托管对象 RC 循环引用、
全局容器只增不减（缓存无淘汰策略）。

static Item* cache[1024]; static int cache_len = 0;
void remember(Item* it) { cache[cache_len++] = it; }   // 只增不减 → 越界 + 泄漏

// 自定义全局分配器，统计分配/释放的字节数
static ALLOCATED: AtomicUsize = AtomicUsize::new(0);
unsafe impl GlobalAlloc for Counting {
    unsafe fn alloc(&self, l: Layout) -> *mut u8 {
        ALLOCATED.fetch_add(l.size(), Ordering::Relaxed); System.alloc(l)
    }
    unsafe fn dealloc(&self, p: *mut u8, l: Layout) {
        ALLOCATED.fetch_sub(l.size(), Ordering::Relaxed); System.dealloc(p, l)
    }
}

排查步骤：周期性打印 ALLOCATED 与 memory.size 页数 → 两者单调上涨即确认泄漏
→ 用 -sASSERTIONS=2 或 ASan 版本定位 → 二分法注释掉一半功能缩小范围。

收益：避免频繁 malloc/free、避免触发内存增长、内存布局可预测且缓存友好。
风险：池满策略必须明确（扩容/拒绝/阻塞）、对象复用必须显式 reset 防串数据、
小对象池化可能不划算。

pub struct Pool<T> { free: Vec<Box<T>>, make: fn() -> T, capacity: usize }
impl<T> Pool<T> {
    pub fn acquire(&mut self) -> Option<Box<T>> {
        self.free.pop().or_else(|| if self.free.len() < self.capacity
            { Some(Box::new((self.make)())) } else { None })
    }
    pub fn release(&mut self, mut item: Box<T>) {
        *item = (self.make)();          // 必须重置，防串数据
        self.free.push(item);
    }
}

实测参考（100 万次对象创建）：malloc/free 约 210 ms，对象池复用约 45 ms
（4.7 倍），arena 整块释放约 18 ms（11 倍）。

const cached = new Float64Array(Module.memory.buffer, 0, 1024);  // 危险：缓存视图
// 任何一次 grow 之后 cached 变成 detached，读写直接抛异常

function readFloat(idx) {                                        // 安全：每次重建
  return new Float64Array(Module.memory.buffer, 0, 1024)[idx];
}

// 模式一：一次性把大数组搬进 WASM，避免逐元素跨边界
const ptr = Module._alloc(n * 4);
new Float32Array(Module.memory.buffer, ptr, n).set(input);
Module._process(ptr, n);
Module._free(ptr);

// 模式二：让 WASM 直接写进 JS 侧提供的缓冲区（同样零拷贝）
Module._fill(ptr, n);
const out = new Float32Array(Module.memory.buffer, ptr, n).slice();  // 需要副本时再拷

零拷贝三个前提：数据在线性内存里且期间不触发增长、JS 视图每次使用前重建、
所有权清晰（谁分配谁释放，避免悬垂指针）。

宿主拥有：宿主分配释放、插件只读（最安全）；插件拥有：插件分配释放、宿主
通过 dealloc 归还；借用：调用期间有效（最高效也最危险）；共享：双方持有，
需引用计数或外部同步。

#[no_mangle]
pub extern "C" fn process(ptr: *const u8, len: usize) -> i32 {
    let input = unsafe { std::slice::from_raw_parts(ptr, len) };  // 仅调用期间有效
    // 绝不能把 input 存进全局 —— 返回后它就是悬垂指针
    input.iter().map(|b| *b as i32).sum::<i32>()
}

多线程共享内存：需要 WebAssembly.Memory({ shared: true }) 与 COOP/COEP 响应头；
共享区必须用原子操作访问，普通读写不保证可见性。

// Rust 侧用原子类型访问共享区
use core::sync::atomic::{AtomicU32, Ordering};
let counter = unsafe { &*(ptr as *const AtomicU32) };
counter.fetch_add(1, Ordering::SeqCst);

emcc app.c -O2 -sINITIAL_MEMORY=64MB -sMAXIMUM_MEMORY=512MB \
  -sALLOW_MEMORY_GROWTH=1 -o app.js

let limits = StoreLimitsBuilder::new().memory_size(512 * 1024 * 1024).build();
store.limiter(|s| &mut s.limits);          // 宿主侧给实例设硬上限

OOM 三个层次：malloc 返回 NULL → 模块检查返回值走降级；grow 返回 -1 →
分配器向上传播失败；触及宿主硬上限 → 宿主捕获 trap 返回 503 并告警。
反面模式：直接 abort 整个实例，导致用户请求全部失败。

char* buf = (char*)malloc(n);
if (buf == NULL) { return ERR_OUT_OF_MEMORY; }   // 降级，而不是继续写空指针

// 用 memory.size 追踪增长次数，用自定义分配器统计字节数
let pages_before = memory.size(&store);
// ... 执行负载 ...
let pages_after = memory.size(&store);
println!("grew {} pages", pages_after - pages_before);

必测四项：增长次数（每次增长都意味着视图失效与停顿）、峰值内存（决定
INITIAL_MEMORY）、malloc/free 调用次数与耗时占比、分配失败与 trap 次数。

[ ] 压测得峰值内存，INITIAL_MEMORY 按峰值设，尽量禁止增长
[ ] 热点路径改用对象池或 arena，减少通用分配器调用
[ ] 大数组走零拷贝，避免逐元素跨边界
[ ] 检查所有 malloc 返回值，OOM 走错误码而非崩溃
[ ] 长跑服务定期观测碎片；SIMD 数据结构显式 16 字节对齐
[ ] 多线程共享区用原子访问，并确认 COOP/COEP 就绪