Allow multiple registration of same image in the GlobalRegistry #10874
Conversation
With `Module::deserialize_raw` it is possible to create multiple `CodeMemory` objects that refer to the same underlying image. This is useful when embedder uses multiple `Engine` objects with different config. Currently this fails on assertion when trying to register same region of code second time in the `global_code` registry. Global code registry stores `Arc<CodeMemory>`, but only needs to access trap data section in the image. Storing list of these in code registry would be silly, because on PC lookup one item would need to be picked arbitrarily, possibly different than the one which is currently executing, only to access `trap_data` field which must be identical for all items. This commit modifies global registry to only store raw pointers to the `trap_data` section along with an usage count. Unregistration is moved into `Drop` guard to ensure that underlying data is not freed before unregistration is manually called.
If the engines have different configs, then the same compiled artifact will not be compatible with all engines, only the one using the config that it was compiled with. |
|
(And if the engines all have the same config, then you might as well just use one engine.) |
|
I think it's not nice if it crashes on assert just because you used same image more than once. There's no such limitation for modules loaded from normal file. (and to be precise there are config settings that are not dependent on the artifact, like stack limits, memory allocators and few others) |
|
One comment on this I've got is that we've generally been trying to reduce |
|
I think avoiding unsafe would require storing registry as |
With
Module::deserialize_rawit is possible to create multipleCodeMemoryobjects that refer to the same underlying image. This is useful when embedder uses multipleEngineobjects with different config. Currently this fails on assertion when trying to register same region of code second time in theglobal_coderegistry.Global code registry stores
Arc<CodeMemory>, but only needs to access trap data section in the image. Storing list of these in code registry would be silly, because on PC lookup one item would need to be picked arbitrarily, possibly different than the one which is currently executing, only to accesstrap_datafield which must be identical for all items.This commit modifies global registry to only store raw pointers to the
trap_datasection along with an usage count. Unregistration is moved intoDropguard to ensure that underlying data is not freed before unregistration is manually called.