Currently all instances of wasmtime::Module have a unique 64-bit id embedded into them. This ID was originally only used for affinity in the pooling allocator as a quick check of module equality. This use case only required engine-local ids so the initial implementation had an ID allocator per-engine.
Later, however, this id was reused for wasmtime::ModuleExport which was intended to skip the string lookup for an export at runtime. This also stored a module id but it did not store an engine identifier. This meant that it's possible to mix these up and pass the wrong export to the wrong engine. This behavior can lead to a runtime panic in Wasmtime.
This commit fixes this by making the module identifier be global per-process instead of per-engine. This mirrors how store IDs are allocated where they're per-process instead of per-engine. The same logic for why store IDs are unlikely to be exhausted applies here too where this 64-bit space of identifiers is unlikely to be exhausted.
Currently all instances of
wasmtime::Modulehave a unique 64-bit id embedded into them. This ID was originally only used for affinity in the pooling allocator as a quick check of module equality. This use case only required engine-local ids so the initial implementation had an ID allocator per-engine.Later, however, this id was reused for
wasmtime::ModuleExportwhich was intended to skip the string lookup for an export at runtime. This also stored a module id but it did not store an engine identifier. This meant that it's possible to mix these up and pass the wrong export to the wrong engine. This behavior can lead to a runtime panic in Wasmtime.This commit fixes this by making the module identifier be global per-process instead of per-engine. This mirrors how store IDs are allocated where they're per-process instead of per-engine. The same logic for why store IDs are unlikely to be exhausted applies here too where this 64-bit space of identifiers is unlikely to be exhausted.