Stream: git-wasmtime

Topic: wasmtime / PR #2086 Refactor where results of compilation...

Wasmtime GitHub notifications bot (Jul 31 2020 at 21:50):

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 a CompiledFunction
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 into wasmtime-jit instead of wasmtime-environ.
This is another goal where wasmtime-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".

Wasmtime GitHub notifications bot (Jul 31 2020 at 21:50):

alexcrichton requested yurydelendik for a review on PR #2086.

Wasmtime GitHub notifications bot (Aug 03 2020 at 15:17):

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 a CompiledFunction
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 into wasmtime-jit instead of wasmtime-environ.
This is another goal where wasmtime-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".

Wasmtime GitHub notifications bot (Aug 03 2020 at 15:37):

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 a CompiledFunction
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 into wasmtime-jit instead of wasmtime-environ.
This is another goal where wasmtime-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".

Wasmtime GitHub notifications bot (Aug 03 2020 at 15:59):

yurydelendik submitted PR Review.

Wasmtime GitHub notifications bot (Aug 03 2020 at 15:59):

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.

Wasmtime GitHub notifications bot (Aug 03 2020 at 15:59):

yurydelendik submitted PR Review.

Wasmtime GitHub notifications bot (Aug 03 2020 at 16:28):

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 a CompiledFunction
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 into wasmtime-jit instead of wasmtime-environ.
This is another goal where wasmtime-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".

Wasmtime GitHub notifications bot (Aug 03 2020 at 16:29):

alexcrichton submitted PR Review.

Wasmtime GitHub notifications bot (Aug 03 2020 at 16:29):

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.

Wasmtime GitHub notifications bot (Aug 03 2020 at 16:34):

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 a CompiledFunction
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 into wasmtime-jit instead of wasmtime-environ.
This is another goal where wasmtime-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".

Wasmtime GitHub notifications bot (Aug 03 2020 at 16:35):

yurydelendik submitted PR Review.

Wasmtime GitHub notifications bot (Aug 03 2020 at 16:44):

yurydelendik submitted PR Review.

Wasmtime GitHub notifications bot (Aug 03 2020 at 17:20):

alexcrichton merged PR #2086.

Last updated: Nov 22 2024 at 16:03 UTC