You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refactor ModuleRegistry to not rely on image layout (#13483)
Prior to this commit the methods of `ModuleRegistry` implicitly relied
on the in-memory layout of compiled modules/components, specifically
that defined functions for modules were the only interesting functions
and they're all clumped in groups. This reliance is surfaced in the
`module_and_code_by_pc` method which was called for various operations
such as when throwing an exception or looking at the stack for GC roots.
In these scenarios, however, there's no need for a `Module` to be used
and instead a bland `CodeMemory` can be used instead.
This commit refactors the internals to no longer look at the
`finished_functions` of a module and also avoid a `BTreeMap` within the
`ModuleRegistry`. By doing so all methods are now fully agnostic to the
internal layout of the code image of a module or component, which in
turn empowers refactoring/moving various items around as needed. This is
needed for an upcoming change I'm making, for example. Internally most
users have moved over to `store_code_by_pc` since the call sites didn't
need a module but instead "just some metadata". The main holdout is the
logic to generate a trap frame from a stack walk. This is enabled by
refactoring the previous `BTreeMap` to instead hold a
`CompiledFunctionsTable`, used to translate a pc to a `FuncKey`, and
then a mapping of `StaticModuleIndex` to `RegisteredModuleId`. This adds
up to the ability to be able to go from an arbitrary pc to a module for
a defined wasm function.
0 commit comments