alexcrichton opened PR #2086 from compile-singular-function
to main
:
This commit refactors the internals of compilation in Wasmtime to change
where results of individual function compilation are stored. Previously
compilation resulted in many maps being returned, and compilation
results generally held all these maps together. This commit instead
switches this to have all metadata stored in aCompiledFunction
instead of having a separate map for each item that can be stored.The motivation for this is primarily to help out with future
module-linking-related PRs. What exactly "module level" is depends on
how we interpret modules and how many modules are in play, so it's a bit
easier for operations in wasmtime to work at the function level where
possible. This means that we don't have to pass around multiple
different maps and a function index, but instead just one map or just
one entry representing a compiled function.Additionally this change updates where the parallelism of compilation
happens, pushing it intowasmtime-jit
instead ofwasmtime-environ
.
This is another goal wherewasmtime-jit
will have more knowledge about
module-level pieces with module linking in play. User-facing-wise this
should be the same in terms of parallel compilation, though.The ultimate goal of this refactoring is to make it easier for the
results of compilation to actually be a set of wasm modules. This means
we won't be able to have a map-per-metadata where the primary key is the
function index, because there will be many modules within one "object
file".
alexcrichton requested yurydelendik for a review on PR #2086.
alexcrichton updated PR #2086 from compile-singular-function
to main
:
This commit refactors the internals of compilation in Wasmtime to change
where results of individual function compilation are stored. Previously
compilation resulted in many maps being returned, and compilation
results generally held all these maps together. This commit instead
switches this to have all metadata stored in aCompiledFunction
instead of having a separate map for each item that can be stored.The motivation for this is primarily to help out with future
module-linking-related PRs. What exactly "module level" is depends on
how we interpret modules and how many modules are in play, so it's a bit
easier for operations in wasmtime to work at the function level where
possible. This means that we don't have to pass around multiple
different maps and a function index, but instead just one map or just
one entry representing a compiled function.Additionally this change updates where the parallelism of compilation
happens, pushing it intowasmtime-jit
instead ofwasmtime-environ
.
This is another goal wherewasmtime-jit
will have more knowledge about
module-level pieces with module linking in play. User-facing-wise this
should be the same in terms of parallel compilation, though.The ultimate goal of this refactoring is to make it easier for the
results of compilation to actually be a set of wasm modules. This means
we won't be able to have a map-per-metadata where the primary key is the
function index, because there will be many modules within one "object
file".
alexcrichton updated PR #2086 from compile-singular-function
to main
:
This commit refactors the internals of compilation in Wasmtime to change
where results of individual function compilation are stored. Previously
compilation resulted in many maps being returned, and compilation
results generally held all these maps together. This commit instead
switches this to have all metadata stored in aCompiledFunction
instead of having a separate map for each item that can be stored.The motivation for this is primarily to help out with future
module-linking-related PRs. What exactly "module level" is depends on
how we interpret modules and how many modules are in play, so it's a bit
easier for operations in wasmtime to work at the function level where
possible. This means that we don't have to pass around multiple
different maps and a function index, but instead just one map or just
one entry representing a compiled function.Additionally this change updates where the parallelism of compilation
happens, pushing it intowasmtime-jit
instead ofwasmtime-environ
.
This is another goal wherewasmtime-jit
will have more knowledge about
module-level pieces with module linking in play. User-facing-wise this
should be the same in terms of parallel compilation, though.The ultimate goal of this refactoring is to make it easier for the
results of compilation to actually be a set of wasm modules. This means
we won't be able to have a map-per-metadata where the primary key is the
function index, because there will be many modules within one "object
file".
yurydelendik submitted PR Review.
yurydelendik created PR Review Comment:
Is it possible to add "CompiledFunction"-lite-like structure to use it with
Compilation
? It does not look like the code above will be easy to maintain.
yurydelendik submitted PR Review.
alexcrichton updated PR #2086 from compile-singular-function
to main
:
This commit refactors the internals of compilation in Wasmtime to change
where results of individual function compilation are stored. Previously
compilation resulted in many maps being returned, and compilation
results generally held all these maps together. This commit instead
switches this to have all metadata stored in aCompiledFunction
instead of having a separate map for each item that can be stored.The motivation for this is primarily to help out with future
module-linking-related PRs. What exactly "module level" is depends on
how we interpret modules and how many modules are in play, so it's a bit
easier for operations in wasmtime to work at the function level where
possible. This means that we don't have to pass around multiple
different maps and a function index, but instead just one map or just
one entry representing a compiled function.Additionally this change updates where the parallelism of compilation
happens, pushing it intowasmtime-jit
instead ofwasmtime-environ
.
This is another goal wherewasmtime-jit
will have more knowledge about
module-level pieces with module linking in play. User-facing-wise this
should be the same in terms of parallel compilation, though.The ultimate goal of this refactoring is to make it easier for the
results of compilation to actually be a set of wasm modules. This means
we won't be able to have a map-per-metadata where the primary key is the
function index, because there will be many modules within one "object
file".
alexcrichton submitted PR Review.
alexcrichton created PR Review Comment:
Yeah that's a good point, I went ahead and updated
Compilation
to have specific accessors for what's needed by wasmtime and now it no longer stores all these fields that are emptied out here.
alexcrichton updated PR #2086 from compile-singular-function
to main
:
This commit refactors the internals of compilation in Wasmtime to change
where results of individual function compilation are stored. Previously
compilation resulted in many maps being returned, and compilation
results generally held all these maps together. This commit instead
switches this to have all metadata stored in aCompiledFunction
instead of having a separate map for each item that can be stored.The motivation for this is primarily to help out with future
module-linking-related PRs. What exactly "module level" is depends on
how we interpret modules and how many modules are in play, so it's a bit
easier for operations in wasmtime to work at the function level where
possible. This means that we don't have to pass around multiple
different maps and a function index, but instead just one map or just
one entry representing a compiled function.Additionally this change updates where the parallelism of compilation
happens, pushing it intowasmtime-jit
instead ofwasmtime-environ
.
This is another goal wherewasmtime-jit
will have more knowledge about
module-level pieces with module linking in play. User-facing-wise this
should be the same in terms of parallel compilation, though.The ultimate goal of this refactoring is to make it easier for the
results of compilation to actually be a set of wasm modules. This means
we won't be able to have a map-per-metadata where the primary key is the
function index, because there will be many modules within one "object
file".
yurydelendik submitted PR Review.
yurydelendik submitted PR Review.
alexcrichton merged PR #2086.
Last updated: Dec 23 2024 at 12:05 UTC